jiebi/CodeConvo huggingface dataset:
Change:
As discussed in Tokyo, forcing your peer to change a connection ID is still possible, but we would require a change in port in order to effect that. .
I don't remember this being what we agreed, and it's not necessary. You only need to change when you see a new path, not after a new CID. That's how we got rid of counting to infinity.
I'm not sure it is always well-defined when you are on a new path and you risk accidental linkage. I believe this was the thinking behind this.
IIRC, NAME is correct; we agreed to do this on peer address change. If you don't know you've been rebound and you reuse a CID, you've already linked yourself; the peer changing CID in response is pointless. If you either anticipate a rebinding or proactively change ports, and change both CID and address simultaneously, then it doesn't matter which of those triggers the peer to switch. If you switch CID without changing address, the address links you with fairly high probability anyway, so it doesn't really matter if the peer switches.
The recommendation exists to avoid linkability across a non-migrating change in connection ID.
I don't think that that's particularly useful, and it seems to create a bunch of new problems.
My recollection is what NAME says. I remember discussing that changing CID on both sides allows a flow to be broken up into flowlets, but if the address is the same on both sides, that's a pretty clear signal anyways. I am fine with requiring a change only if the peer's CID and address change.
That is not sufficient because the client could be migrating from domestic wifi to mobile, to train wifi, while the server always sees the IP address of the load balancer.
In this case the LB and the server should be regarded as the same thing, and it's the LB's job to convey that somehow.
FWIW, it helps when you have multiple connections coalesced onto a 5-tuple. An endpoints rotates the sending CIDs of all the connections at once, and that triggers the peer to rotate all of it's sending CIDs at once. Then, it becomes very hard for an observer to track the individual connections.
Tokyo:
That being (I'm closing ).
This was

Discussion:
reset its congestion state (see migration-cc), so the port SHOULD only be changed infrequently. <del> Endpoints that use connection IDs with length greater than zero could have their activity correlated if their peers keep using the same destination connection ID after migration.  The goal is to ensure that packets sent on different paths cannot be correlated.  To </del> <ins> Endpoints that supply connection IDs with length greater than zero could have their activity correlated if their peers keep using the same destination connection ID after migration.  To ensure that packets sent on different paths cannot be correlated, endpoints SHOULD provide with new connection IDs before peers migrate.  To </ins> fulfill this privacy requirement, endpoints that initiate migration and use connection IDs with length greater than zero SHOULD provide their peers with new connection IDs before migration.
Change:
NAME this is annoyingly close to done. Would you mind?
NAME : Take a look.
LGTM

Discussion:
perform path validation (migrate-validate) if it detects a change in the IP address of its peer. <ins> When an endpoint has no validated path on which to send packets, it MAY discard connection state.  An endpoint capable of connection migration MAY wait for a new path to become available before discarding connection state. </ins> This document limits migration of connections to new client addresses, except as described in preferred-address.  Clients are responsible for initiating all migrations.  Servers do not send non-

10. <del> Connections should remain open until they become idle for a pre- negotiated period of time.  A QUIC connection, once established, can be terminated in one of three ways: </del> <ins> An established QUIC connection can be terminated in one of three ways: </ins> idle timeout (idle-timeout)

stateless reset (stateless-reset) <ins> An endpoint MAY discard connection state if it does not have a validated path on which it can send packets (see migrate-validate). </ins> 10.1. The closing and draining connection states exist to ensure that
Change:
Separately from this, I note that Security Considerations is becoming more of a jumbled bag of waving at various concerns. Some organization and expanded text around each topic might be warranted.
Can you add a sub-heading(##) for each of these considerations, like in the transport draft? Originally posted by NAME in URL
Seems mostly right. Though I would prefer something that simply highlighted the fact that a remote address is not expected to be stable over the lifetime of a connection. Therefore, decisions that use an address as input need to either keep up to date, or accept the consequences of not doing so. I would also point out that this is true even if migration is disabled.The text looks great. I really appreciate the fact that we have a recommendation on what IP address we should associate with logging (and address-based authentication).

Discussion:
implementer.  An implementation MUST ensure that the length of a frame exactly matches the length of the fields it contains. <ins> Certain HTTP implementations use the client address for logging or access-control purposes.  Since a QUIC client's address might change during a connection (and future versions might support simultaneous use of multiple addresses), such implementations will need to either actively retrieve the client's current address or addresses when they are relevant or explicitly accept that the original address might change. </ins> 10. 10.1.
Change:
by discarding packets which are "inconsistent with the state of the connection." Previously, this was only a failure to remove packet protection; incorrect version is added as another example inconsistency. Note that this phrasing doesn't rule out upward-VN like , since receiving an expected upgrade is not inconsistent with your local state.
I'm wondering if there is a difference between failed decryption and version number. If the versions differ, it doesn't really make sense to try to read a subsequent coalesced packet, unless you want to do trial and error since the concepts of coalescing and length fields are not defined in the general case. Even if you understand the version, two version can not (or should not?) exist in the same datagram. If packet protection fails on the same version, it might just be a timing issue, or the (to me) dreaded path probe with prefixed knowingly invalid handshake.
That's an interesting question. The Length field is version-specific. If you include it, you can have no expectation that a peer which doesn't speak that version will even be able to find anything further in the datagram -- as far as it knows, the remainder of the datagram is that connection. But that actually has a potential use. On receipt, if the logic first attempts to chunk up the datagram and the subsequent packet is the correct version for the connection, then acknowledging that second coalesced packet implies that you support the first packet's version.

Discussion:
stateless reset allows a peer to more quickly identify when a connection becomes unusable. <del> Packets that are matched to an existing connection, but for which the endpoint cannot remove packet protection, are discarded. </del> <ins> Packets that are matched to an existing connection are discarded if the packets are inconsistent with the state of that connection.  For example, packets are discarded if they indicate a different protocol version than that of the connection, or if the removal of packet protection is unsuccessful once the expected keys are available. </ins> Invalid packets without packet protection, such as Initial, Retry, or Version Negotiation, MAY be discarded.  An endpoint MUST generate a
Change:
A couple of clarifications that can be useful to people who are looking at *PACK for the first time like myself. Not sure about the normative language though. I can reword it if necessary.
Let's see how handles it: We could simply add similar verbiage to Sections and 4.5.5. of the QPACK draft instead.
NAME I can add something like that, but TBH I don't think that the HPACK wording would have helped me, so I'd rather keep my clarification (that says "ignore value") as well.
This wording seems fine.

Discussion:
fields, each of which has a fixed index over time.  Its entries are defined in static-table. <ins> All entries in the static table have a name and a value.  However, values can be empty (that is, have a length of 0). </ins> Note the QPACK static table is indexed from 0, whereas the HPACK static table is indexed from 1.

an absolute index greater than or equal to the Base, the representation starts with the '0000' four-bit pattern. <ins> Only the header field name stored in the static or dynamic table is used.  Any header field value MUST be ignored. </ins> The following bit, 'N', indicates whether an intermediary is permitted to add this header to the dynamic header table on subsequent hops.  When the 'N' bit is set, the encoded header MUST
Change:
This includes the suggestion from NAME to remove the 0-RTT text. Plus some text explaining the choice of label.

Discussion:
of the TLS handshake messages being integrated into the calculation of secrets, the inclusion of the QUIC transport parameters extension ensures that handshake and 1-RTT keys are not the same as those that <del> might be produced by a server running TLS over TCP.  However, 0-RTT keys only include the ClientHello message and might therefore use the same secrets.  To avoid the possibility of cross-protocol key synchronization, additional measures are provided to improve key separation. </del> <ins> might be produced by a server running TLS over TCP.  To avoid the possibility of cross-protocol key synchronization, additional measures are provided to improve key separation. </ins> The QUIC packet protection keys and IVs are derived using a different label than the equivalent keys in TLS. To preserve this separation, a new version of QUIC SHOULD define new labels for key derivation for packet protection key and IV, plus the <del> header protection keys. </del> <ins> header protection keys.  This version of QUIC uses the string "quic". Other versions can use a version-specific label in place of that string. </ins> <del> The initial secrets also use a key that is specific to the negotiated QUIC version.  New QUIC versions SHOULD define a new salt value used in calculating initial secrets. </del> <ins> The initial secrets use a key that is specific to the negotiated QUIC version.  New QUIC versions SHOULD define a new salt value used in calculating initial secrets. </ins> 10.
Change:
For and NAME
Thanks
Note that section 17.2.3. 0-RTT does not mention 0-RTT CID but the following section 7.2.4. Handshake Packet does mention Handshake CID's. In existing draft.
LGTM, given the incorporated changes.

Discussion:
size for every QUIC version it supports. The client populates the Source Connection ID field with a value of <del> its choosing and sets the SCIL field to match. </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 Connection ID values as the client's first Initial. </ins> The Destination Connection ID field in the server's Initial packet contains a connection ID that is chosen by the recipient of the

On first receiving an Initial or Retry packet from the server, the client uses the Source Connection ID supplied by the server as the <del> Destination Connection ID for subsequent packets.  That means that a client might change the Destination Connection ID twice during connection establishment, once in response to a Retry and once in response to the first Initial packet from the server.  Once a client has received an Initial packet from the server, it MUST discard any packet it receives with a different Source Connection ID. </del> <ins> Destination Connection ID for subsequent packets, including any subsequent 0-RTT packets.  That means that a client might change the Destination Connection ID twice during connection establishment, once in response to a Retry and once in response to the first Initial packet from the server.  Once a client has received an Initial packet from the server, it MUST discard any packet it receives with a different Source Connection ID. </ins> A client MUST only change the value it sends in the Destination Connection ID in response to the first packet of each type it
Change:
This is fine, but I think that we want chairs to call it.
This falls under the new process, so it's upto the chairs.
Based on the discussion in I think this has rough consensus. Tagging as such and reassigning.
Slow down, we're not in the new process yet. And, in either case, consensus needs to be determined on-list, not in issues.
Currently, the t is in units of seconds. This seems to be too restrictive and not very future proof. Additionally, from an API perspective, most other timers are settable on the millisecond scale, so it creates a kind of ugly discrepancy between all the different timers settable by the app if just one of them has units of seconds. I propose we change the units from seconds to milliseconds. The change both for implementations and spec should be minimal, and it makes things (timers) a little more consistent.
This seems sensible to me both for consistency and I can imagine cases when one would want to specify a fraction(ie: 1/2 of a second).
Agreed. A second is an eternity for a intra-datacenter connection for example. For future proofing all time units should be at least msec IMO.
Don't we want to specify a minimum value now?
No, I don't think so. Even before, if you had a greater than 1 sec RTT (somehow...) if you set an idle timeout of 1 second it would cause you problems. I think bottom line you be smart about your idle timeout values. If you set too small a value you can unnecessarily kill your own connection.
As NAME says, actual idle timeout depends on RTT, and that’s what we have adopted in .
This SGTM.
I support this
I think this has rough consensus. Tagging as such and reassigning.
LG, but I don't know what process this falls under. I'll let NAME and NAME decide.

Discussion:
original_connection_id transport parameter if it sent a Retry packet. <del> The idle timeout is a value in seconds that is encoded as an </del> <ins> The idle timeout is a value in milliseconds that is encoded as an </ins> integer, see (idle-timeout).  If this parameter is absent or zero then the idle timeout is disabled.
Change:
From reading the text, it was not clear that the timer is set based on the last (and not the first) crypto packet sent.
LGTM. I've reworded a bit.

Discussion:
acknowledgement is received, a new RTT is computed and the timer SHOULD be set for twice the newly computed smoothed RTT. <del> When crypto packets are sent, the sender MUST set a timer for the crypto timeout period.  Upon timeout, the sender MUST retransmit all </del> <ins> When a crypto packet is sent, the sender MUST set a timer for the crypto timeout period.  This timer MUST be updated when a new crypto packet is sent.  Upon timeout, the sender MUST retransmit all </ins> unacknowledged CRYPTO data if possible. Until the server has validated the client's address on the path, the
Change:
This doesn't seem implementable without a list of all the things that were sufficient.
That is the list. If you think it should be reworded, I'm happy to take a PR.

Discussion:
connection is in the draining state. An endpoint MAY transition from the closing period to the draining <del> period if it can confirm that its peer is also closing or draining. Receiving a CONNECTION_CLOSE frame is sufficient confirmation, as is receiving a stateless reset.  The draining period SHOULD end when the closing period would have ended.  In other words, the endpoint can use the same end time, but cease retransmission of the closing packet. </del> <ins> period if it receives a CONNECTION_CLOSE frame or stateless reset, both of which indicate that the peer is also closing or draining. The draining period SHOULD end when the closing period would have ended.  In other words, the endpoint can use the same end time, but cease retransmission of the closing packet. </ins> Disposing of connection state prior to the end of the closing or draining period could cause delayed or reordered packets to be
Change:
Simply making this consistent through the document by doing the minimal change and removing leading 0s. Happy to add them if we prefer.
Works for me.

Discussion:
4.2.3. <del> The PRIORITY (type=0x02) frame specifies the client-advised priority </del> <ins> The PRIORITY (type=0x2) frame specifies the client-advised priority </ins> of a request, server push or placeholder. A PRIORITY frame identifies an element to prioritize, and an element

4.2.6. <del> The PUSH_PROMISE frame (type=0x05) is used to carry a promised request header set from server to client on a request stream, as in HTTP/2. </del> <ins> The PUSH_PROMISE frame (type=0x5) is used to carry a promised request header set from server to client on a request stream, as in HTTP/2. </ins> The payload consists of:
Change:
The deleted parenthetical is not accurate, and is unnecessary: 0-RTT and 1-RTT with various key phases share a PN space without sharing keys. I prefer the MUST NOT in coalescing, but if there are objections I can revert it.
Thanks Martin.
All good apart from the MUST NOT. I'm with Martin -- everything else looks fine.

Discussion:
Packet numbers are limited to this range because they need to be representable in whole in the Largest Acknowledged field of an ACK frame (frame-ack).  When present in a long or short header however, <del> packet numbers are reduced and encoded in 1 to 4 bytes, see packet- </del> <ins> packet numbers are reduced and encoded in 1 to 4 bytes (see packet- </ins> encoding). <del> Version Negotiation (packet-version) and Retry packet-retry packets </del> <ins> Version Negotiation (packet-version) and Retry (packet-retry) packets </ins> do not include a packet number. Packet numbers are divided into 3 spaces in QUIC: <del> Initial space: All Initial packets packet-initial are in this </del> <ins> Initial space: All Initial packets (packet-initial) are in this </ins> space. <del> Handshake space: All Handshake packets packet-handshake are in </del> <ins> Handshake space: All Handshake packets (packet-handshake) are in </ins> this space. Application data space: All 0-RTT and 1-RTT encrypted packets <del> packet-protected are in this space. </del> <ins> (packet-protected) are in this space. </ins> As described in QUIC-TLS, each packet type uses different protection keys.

types. A QUIC endpoint MUST NOT reuse a packet number within the same packet <del> number space in one connection (that is, under the same cryptographic keys).  If the packet number for sending reaches 2^62 - 1, the sender MUST close the connection without sending a CONNECTION_CLOSE frame or any further packets; an endpoint MAY send a Stateless Reset (stateless-reset) in response to further packets that it receives. </del> <ins> number space in one connection.  If the packet number for sending reaches 2^62 - 1, the sender MUST close the connection without sending a CONNECTION_CLOSE frame or any further packets; an endpoint MAY send a Stateless Reset (stateless-reset) in response to further packets that it receives. </ins> A receiver MUST discard a newly unprotected packet unless it is certain that it has not processed another packet with the same packet
Change:
Just so you don't have to read the whole RFC7301.
Yeah I was thinking about that. I wonder if it would make sense for the client to simply send PROTOCOL_VIOLATION instead of a TLS alert.
NAME I added a clarification to allow clients to send noapplicationnegotiated as well. Should I send an email to the mailing list for discussion now that the new process is in effect?
Unfortunately yes. This is a design change so it will need an issue as well. I like it and we should do it, but can you add the error code we would use in CONNECTION_CLOSE to the text?
NAME ok, added error code, created issue () and sent email to the list.
NAME thanks, suggestions accepted.
PR added a requirement for end-points to terminate a connection if ALPN negotiation fails, but doesn't specify an error code for this situation. RFC7301 defines the alert that must be used by TLS servers, so QUIC servers should probably use that as well. As for clients, RFC7301 doesn't specify a behaviour, but it also doesn't forbid use of in clients, and it seems better if QUIC clients use the same error code as the servers. Proposed wording change is in .
My :+1: goes to making the change, though I would like to confirm that it wouldn't be illegal for a client to close the connection with error after it sends ClientFinished. I ask this because depending on the design of the TLS stack, the QUIC stack might not be able to see the result of ALPN before the TLS stack generates a ClientFinished (note that EE.ALPN and ServerFinished might arrive in one packet). It's my understanding that the intent of the issue is to not allow the client to send any application data on ALPN failure. Assuming that's true, sending the alert after ClientFinished should be fine.
Yes, I think that would be fine. I don't think that we would be able to guarantee that the alert goes out before sending ClientFinished either. It's certainly possible, but I can see how it might be tricky.
This was fixed with .
a few nits

Discussion:
Negotiation (ALPN) RFC7301 to select an application protocol.  Unless another mechanism is used for agreeing on an application protocol, endpoints MUST use ALPN for this purpose.  When using ALPN, endpoints <del> MUST abort a connection if an application protocol is not negotiated. </del> <ins> MUST immediately close a connection (see Section 10.3 in QUIC- TRANSPORT) if an application protocol is not negotiated with a no_application_protocol TLS alert (QUIC error code 0x178, see tls- errors).  While RFC7301 only specifies that servers use this alert, QUIC clients MUST also use it to terminate a connection when ALPN negotiation fails. </ins> An application-layer protocol MAY restrict the QUIC versions that it can operate over.  Servers MUST select an application protocol