jiebi/CodeConvo huggingface dataset:
Change:
7.2. <ins> Once the handshake is complete, it is possible for either side to update its sending traffic keys using the KeyUpdate handshake message key-update.  The next generation of traffic keys is computed by generating traffic_secret_N+1 from traffic_secret_N as described in this section then re-deriving the traffic keys as described in traffic-key-calculation. The next-generation traffic_secret is computed as: traffic_secret_N+1 = HKDF-Expand-Label(traffic_secret_N, "traffic secret", "", L) Once traffic_secret_N+1 and its associated traffic keys have been computed, implementations SHOULD delete traffic_secret_N.  Once the directional keys are no longer needed, they SHOULD be deleted as well. 7.3. </ins> The traffic keying material is generated from the following input values:

Discussion:
Is good.
The counter has a size of (2^64-1).The records are max (2^14 + 2048). So, my bold calculation would come to (2^64-1) / (2^14 + 2048) / 2^40 = 910.22 TiB of data. In Big Data, video streaming and other mass data cases 910TB data can be a limitation. I would like to propose the counter to go to 2^128-1, which would result in a connection that can reach (2^128-1) / (2^14 + 2048) / 2^80 = 1.52 * 10^10 YiB. If byte preservation is an issue, I'm willing to accept 2^96-1 as the counter max, resulting in (2^96-1) / (2^14 + 2048) / 2^80 = 3.55 YiB as maximum connection.
On a 40Gibit line this will take less time than one might expect: URL (let's say 2.5-3 days with overhead).
Why do you divide by (2^14 + 2048)? Shouldn't it be a multiplication with the minimum record size?
I don't see much support for this. Please take it to the list if you want to pursue it.
Consensus at interim: No protocol action needed. Add calculations to security considerations.
Also, consensus is that the math above is wrong.
NAME would you be willing to contribute a PR with a paragraph or two of guidance on the limits for AES-GCM and ChaCha20
Yes. What happened to the Key Update message? I can't find it in the text, and that would be a logical place to mention the limitations as well as in the security considerations section.
URL If you want to just send a PR against that branch that would be fine. Or really, whatever form you want and I can manually merge.
If we ditch renegotiation (), then we will need a way to rekey sessions to extend their lifetime. Nico suggests that sending ChangeCipherSpec and then using an increasing counter to extract new keys (i.e., add a counter to the key expansion PRF input), which would seem to be sufficient.

We have asked David McGrew about the theoretical limits on AES-GCM, we can find the same info for ChaCha+Poly1305. When we have that info, we will make an assessment as to how urgent this is. That will determine how soon we define this mechanism. NAME noted that you don't even have to negotiate to enable rekeying: if you send the rekey message and rekey, your connection will either be rekeyed, or killed by the peer.
Change:
MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. <ins> Extensions MAY define a different mechanism to negotiate the presence of contexts, and they MAY do so in a way which is opaque to intermediaries. </ins> 4.3. The CLOSE_DATAGRAM_CONTEXT capsule (type=0x01) allows an endpoint to

Discussion:
Contexts are end-to-end, and intermediaries MUST NOT parse them.
In , capsules, contexts and context IDs are explicitly defined as end-to-end and there are requirements for intermediaries to not modify them, and to not even parse them. The motivation for this was to ensure that we retain the ability to deploy extensions end-to-end without having to modify intermediaries. NAME mentioned that these requirements might be too strict, as he would like to have his intermediary be able to parse the context ID, for logging purposes.
Part of the comment from the PR is also about consistency of interface for generic HTTP libraries that can be used to build either endpoints or intermediaries. If the context ID is always present, it's overly prescriptive to say that an intermediary can't parse it, and such a requirement couldn't be enforced anyways. If context IDs are negotiated on/off, whether this is possible depends on the negotiation mechanism.
I think its fine for a component that has bytes passing through it to look at those bytes. The import thing to do is set expectations on what that means for the protocol behaviour we are defining. We don't expect intermediaries to do anything with a context ID; they should not enforce the protocol semantic rules (odd, even, reuse etc). H2 and H3 somewhat solve this problem by decoupling frame parsing from frame payload interpretation. E.g. if the form of a request or response is invalid, an intermediary shouldn't pass it on. DATAGRAM is different because it isn't defined as an actual HTTP/3 frame with frame headers and frame payload. Something that might work is to formalise that quarter stream ID is part of the envelope that intermediaries have to be able to handle the syntax of, but context ID is part of content and separate.
Unless you encrypt capsules end-to-end, I don't think any text in the spec can in practice prevent intermediaries from inspecting and modifying capsules. You can send something like GREASE capsules, though.
LGTM! :shipit:
Change:
mechanism. A second approach places the onus of timekeeping solely on the <del> appraising entity, i.e., the Verifier (for Evidence), or the Relying Party (for Attestation Results), and might be suitable, for example, in case the Attester does not have a reliable clock or time </del> <ins> appraiser, i.e., the Verifier (for Evidence), or the Relying Party (for Attestation Results), and might be suitable, for example, in case the Attester does not have a reliable clock or time </ins> synchronisation is otherwise impaired.  In this approach, a non- predictable nonce is sent by the appraising entity, and the nonce is then signed and included along with the Claims in the Evidence or

Discussion:
Looked at all uses of "entity" in the doc to be sure it wasn't referring to Verifier or RP which are roles and found a few issues in the Freshness section.
Change:
versions without retaining state.  Though either the Initial packet or the Version Negotiation packet that is sent in response could be lost, the client will send new packets until it successfully receives <del> a response or it abandons the connection attempt. </del> <ins> a response or it abandons the connection attempt.  As a result, the client discards all state for the connection and does not send any more packets on the connection. </ins> A server MAY limit the number of Version Negotiation packets it sends.  For instance, a server that is able to recognize packets as

Discussion:
Just in case it wasn't perfectly clear from the choice of words.
I know how you feel. We'll be defining "the" eventually. I don't know where the line is, but I think that it helps in this case to be doubly explicit.
I'm wondering how one could possibly misinterpret "abandoning" here. Furthermore, I don't think it's relevant for the server here if the client actually discarded the connection state, as long as it doesn't any more packets.
I don't think we need to spend a lot of energy here. I agree that this doesn't seem necessary, but I'm not going to fight it either.
The draft currently reads: "When a client receives a Version Negotiation packet, it MUST abandon the current connection attempt." However, it does not define what it is to abandon a connection attempt. Is it an abrupt termination without writing a connection close? That probably makes the most sense since the server is meant to be stateless at this stage.
Do we really need to define "abandon"? And if so, don't we need to define what "discarding" means?LGTM
Change:
An Identifier is a characteristic of the User Equipment used by the components of a Captive Portal to uniquely determine which specific <del> User Equipment is interacting with them.  An Identifier MAY be a </del> <ins> User Equipment is interacting with them.  An Identifier can be a </ins> field contained in packets sent by the User Equipment to the External <del> Network.  Or, an Identifier MAY be an ephemeral property not </del> <ins> Network.  Or, an Identifier can be an ephemeral property not </ins> contained in packets destined for the External Network, but instead correlated with such information through knowledge available to the different components.

Discussion:
We were unnecessarily using normative language in section 3.1. Replace it with non-normative language.
Alvaro writes of possibilities. Replace the two 'MAY' occurrences with 'could'.
Change:
to link utilization, which can impact performance over some types of network.  Applications might be able to improve overall performance by using alternative strategies that reduce the rate of <del> acknowledgments. </del> <ins> acknowledgments.  I-D.ietf-quic-ack-frequency describes an extension to signal the desired delay of acknowledgments and discusses use cases as well as implications for congestion control and recovery. </ins> 8.

Discussion:
Section 7 talks about acknowledgment strategy, but it is not actually giving any examples of what the application can do. Since it is kind of a transport layer property and not an application layer property, it is unclear how an application [developer] can replace the "TCP like ack every other packet" functionality. Are there QUIC options to consider that do this? If so, why not mention those here?
I guess there is draft URL but not sure we want to add a reference...?
I guess we should at least add a reference to URL however that is currently expired :-(
I've sent a reply to Paul by email and waiting for a response now.
Unsure why we would specifically reference this rather than other work: draft-li-quic-optimizing-ack-in-wlan/, I expect the correct thing is to reference a WG RFC, and section 2.5 of RFC9065 is one way. Citing the WG ack frequency draft might additionally be useful.
For the record, this is what I replied by mail: "[MK] This is a whole research area of its own... however, I create an issue to see if people think adding some reference might be useful. There is a wg draft in QUIC for an extension to negotiate the ack frequency and there is another individual draft about strategies for WLANs. Still, this is also not really QUIC specific. Similar proposals also exists for TCP. The difference is that with TCP the network can also do ACK thinning which is not possible with QUIC anymore."
NAME but RFC9065 section 2.5 doesn't talk about acks at all... I still propose to add a reference to URL as this is a wg doc at least.
Change:
such that its length equals the size of the largest possible Certificate (message) covered by the same ESNI key.  Moreover, the server MUST include the "encrypted_server_name" extension in <del> EncryptedExtensions, and the value of this extension MUST match PaddedServerNameList.nonce. </del> <ins> EncryptedExtensions with the "response_type" field set to "esni_accept" and the "nonce" field set to the decrypted PaddedServerNameList.nonce value from the client "encrypted_server_name" extension. If the server sends a NewSessionTicket message, the corresponding ESNI PSK MUST be ignored by all other servers in the deployment when not negotiating ESNI, including servers which do not implement this specification.  This may be implemented by adding a new field to the server session state which earlier implementations cannot parse. This restriction provides robustness for rollbacks (see misconfiguration). </ins> 5.4.

Discussion:
(WG email coming shortly.) ESNI has different compatibility characteristics than most TLS extensions. It involves client state, and encrypting the SNI makes the ClientHello unusable for servers that do not have the key or do not implement ESNI. This breaks common rollout and rollback strategies and places strong requirements on DNS/server consistency. This makes deploying ESNI risky for servers. This change aims to reduce these deployment risks. ESNI is much more useful if widely deployed. Moreover, if ESNI is unreliable due to complex requirements on the server, clients will be disincentivized to implement it. The DNS/server consistency requirements also disincentivize rotating keys (section 7.2.5). This change introduces the notion of a "public name" which allows the client to receive authenticated signals from the server that the ESNIKeys are out of sync, so clients can safely repair key mismatches. It also aligns with existing server behavior before ESNI, so partial rollouts and rollbacks can also be handled. The fix for the latter also handles MITM scenarios, replacing the existing client recommendation: The public name notion fixes a bug in that text: an attacker could disable ESNI on all servers, given the existence of any such server.
And, as I write this, I realize I forgot to deal with Stephen's comment on the thread about the middlebox stuff! It's quite late here, so I will reword that tomorrow morning.
Currently, the connect fails when a mismatch occurs. An alternative strategy might be to return a new ESNI key that is then used for a subsequent connection.
How to understand the reliability of the public key from server?
I see that I missed something about disabling. I think that this could be a lot more explicit about the three primary cases that I talk about in the comments below.Looks mostly good, but added some nits and clarification questions.
Change:
sctp-sdp.  The "fmt" value MUST be set to "webrtc-datachannel" as specified in I-D.ietf-mmusic-sctp-sdp, Section 4.1. <del> Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd", "a=fingerprint", "a=dtls-id", and "a=setup" lines MUST be included as mentioned above, along with an "a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp-sdp, Section 4.1. </del> <ins> Within the data m= section, an "a=mid" line MUST be generated and included as described above, along with an "a=sctp-port" line referencing the SCTP port number, as defined in I-D.ietf-mmusic-sctp- sdp, Section 5.1, and, if appropriate, an "a=max-message-size" line, as defined in I-D.ietf-mmusic-sctp-sdp, Section 6.1. As discussed above, the following attributes are included only if the m= section either has a unique address or is associated with the bundle-tag: "a=ice-ufrag", "a=ice-pwd", "a=fingerprint", "a=dtls-id", and "a=setup". </ins> Once all m= sections have been generated, a session-level "a=group" attribute MUST be added as specified in RFC5888.  This attribute MUST

Discussion:
NAME revised
Fixed by
Maybe in create-answer as well
The "Initial Offers" section does not distinguish systematically between requirements that apply for any type of offer and the ones that apply only to mediastreams. For instance: I think this should apply both to mediastreamtrack and to datachannels. Then many of the rules described under "Each m= section MUST include the following attribute lines:" seem specific to mediastreams, but not all; and that set of rules is then followed by a statement that a m= section must be created for data channels. This could use some reorganization and clarification.
Agree this could be refactored a bit. Magnus had a similar comment in the past.
Suggest contact with Magnus or Jessep for potential language.
I think this is mostly editorial and as such probably needs to be resolved within the author team.
Can this be considered fixed now? The createOffer section has since been structured into "here's what you generate for each RtpTransceiver", "here's what you generate if there's a data channel". And the data channel requirements look complete to me:
I agree with NAME NAME shall we close this?
I think the concern was that the data channel paragraphs feel a bit like an afterthought. I think this could be improved, but I don't think the current situation is dire.
I can live with the current text as is. Done is a feature and I don't think this will cause any interoperability problems.
This text has been improved as of PR . If we can and this text still reads well, I think we can close this issue.
Pending resolution of
is it's own bug. I think we an just close this and any changes needed can be dealt with by
I want to take one last editorial pass over the text once lands. This is a purely editorial issue at this point.
Change:
an authenticator <ins> a function for validating a certificate chain </ins> It returns the identity, such as the certificate chain and its extensions, and a status to indicate whether the authenticator is <del> valid or not.  The API SHOULD return a failure if the certificate_request_context of the authenticator was used in a previously validated authenticator.  Well-formed empty authenticators are returned as valid. </del> <ins> valid or not after applying the function for validating the certificate chain to the chain contained in the authenticator. The API SHOULD return a failure if the certificate_request_context of the authenticator was used in a previously validated authenticator. Well-formed empty authenticators are returned as invalid. </ins> 8.

Discussion:
one minor nit: i would phrase "applying the function for validating the certificate chain contained in the authenticator." as "applying the function for validating the certificate chain to the chain contained in the authenticator." for clarity. Otherwise LGTM!
I've implemented earlier drafts. I do have a concern with the validate API as presented in the draft: it treats empty authenticators as valid, and then returns the identity as a certificate chain that must be validated by the application. Similar APIs have lead to easily foreseeable pwnage. Instead I would recommend the validate API carry out X509 validation against a trust store or validation function and treat the empty authenticator as invalid. That way someone has to think before not checking the certificate returned.
Closing this out as it was addressed.
Change:
of-Possession (PoP) token by default. This document follows RFC7800 for PoP semantics for JWTs (CWTs MAY <del> also be used).  The AS includes a "cnf" (confirmation) parameter to </del> <ins> also be used).  The AS includes a "cnf" (confirmation) parameter in </ins> the PoP token, to declare that the Client possesses a particular key and RS can cryptographically confirm that the Client has possession <del> of that key.  The "cnf" parameter is REQUIRED if a symmetric key is used, and MAY be present for asymmetric PoP keys, as described in I- D.ietf-ace-oauth-params. </del> <ins> of that key, as described in I-D.ietf-ace-oauth-params. </ins> Note that the contents of the web tokens (including the "cnf" parameter) are to be consumed by the RS and not the Client (the

Discussion:
Let's assume we're talking about what the AS puts in the token (not the token response). That means that "cnf" always has to be present. The flow where "cnf" is only required in the symmetric case and is optional for the asymmetric case is the use of the "cnf" parameter in the token response, from AS to client.
Change:
13. <ins> I-D.draft-ietf-quic-datagram specifies a QUIC extension to enable sending and receiving unreliable datagrams over QUIC.  Unlike operating directly over UDP, applications that use the QUIC datagram service do not need to implement their own congestion control, per RFC8085, as QUIC datagrams are congestion controlled. QUIC datagrams are not flow-controlled, and as such data chunks may be dropped if the receiver is overloaded.  While the reliable transmission service of QUIC provides a stream-based interface to send and receive data in order over multiple QUIC streams, the datagram service has a unordered message-based interface.  If needed, an application layer framing can be used on top to allow separate flows of unreliable datagrams to be multiplexed on one QUIC connection. 14. </ins> This document has no actions for IANA; however, note that ports recommends that application bindings to QUIC for applications using TCP register UDP ports analogous to their existing TCP registrations. <del> 14. </del> <ins> 15. </ins> See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for

Discussion:
I updated the text of the second paragraph. If people could have another look that would be welcome. But I believe we are ready to merge (after the meeting).
So far we don't mention any extension in the ops drafts, however, datagrams actually require a different interface and as such are important for an application to know about, therefore, I think it would be good to add a separate section in the applicability statement and mention it as a separate service over QUIC.
Agreed, mentioning datagram seems very useful.
Change:
this extension, when applicable. All certificates provided by the server MUST be signed by a signature <del> algorithm that appears in the "signature_algorithms" extension provided by the client, if they are able to provide such a chain (see signature-algorithms).  Certificates that are self-signed or certificates that are expected to be trust anchors are not validated as part of the chain and therefore MAY be signed with any algorithm. </del> <ins> algorithm advertised by the client, if they are able to provide such a chain (see signature-algorithms).  Certificates that are self- signed or certificates that are expected to be trust anchors are not validated as part of the chain and therefore MAY be signed with any algorithm. </ins> If the server cannot produce a certificate chain that is signed only via the indicated supported algorithms, then it SHOULD continue the handshake by sending the client a certificate chain of its choice that may include algorithms that are not known to be supported by the client.  This fallback chain SHOULD NOT use the deprecated SHA-1 hash <del> algorithm in general, but MAY do so if the "signature_algorithms" extension provided by the client permits it, and MUST NOT do so otherwise. </del> <ins> algorithm in general, but MAY do so if the client's advertisement permits it, and MUST NOT do so otherwise. </ins> If the client cannot construct an acceptable chain using the provided certificates and decides to abort the handshake, then it MUST abort

Discussion:
In your answer to my question on list you say: and chain validation. I don't see that covered by this PR. Shouldn't this be explicit?
then the "signature_algorithms" extension also applies to signatures appearing in certificates. is unaffected by this change
As NAME says, there is already text that implies that you need not send "signature_algorithms" cert, so I don't think new text is really needed here.
That sentence says nothing about under what circumstances it is ok to omit "signaturealgorithmscert". It only implies that you may not always get it. I think it would not hurt to be more explicit.