jiebi/CodeConvo huggingface dataset:
Change:
frames uses the following format (using the notation from the "Notational Conventions" section of QUIC): <del> A variable-length integer indicating the Flow Identifier of the datagram (see flow-id). </del> <ins> A variable-length integer indicating the Flow ID of the datagram (see datagram-flows). </ins> The payload of the datagram, whose semantics are defined by individual applications.  Note that this field can be empty. Endpoints MUST treat receipt of a DATAGRAM frame whose payload is too <del> short to parse the flow identifier as an HTTP/3 connection error of type H3_GENERAL_PROTOCOL_ERROR. </del> <ins> short to parse the flow ID as an HTTP/3 connection error of type H3_GENERAL_PROTOCOL_ERROR. </ins> 5.

Discussion:
This somewhat of an experiment. While trying to address I got distracted by the document's use of the "flow identifier" term. The document likes to compare "flow identifiers" with QUIC streams, which is fine. But QUIC makes the distinction between streams and stream IDs; the ID is a property of the stream but it isn't the only one, and sometimes it helps to talk about the stream in other contexts. This change tries to channel a similar editorial style. It replaces: "flow identifiers" with "flows" when talking about a logical entitiy "flow identifiers" with "flow IDs" when talking about the wire format, encoding, examples etc. This could be a change too far but I figured it would be a good discussion starter.
The draft doesn't do this. It relies on the QUIC varint encoding for non-negativity in DATAGRAM frames but could contain a negative value. Let's be clear in the spec.
Definitely agree, could you write a PR please?
I will.
fixed in URL
Thanks!
Change:
6.4. <ins> A Retry or Version Negotiation packet causes a client to send another Initial packet, effectively restarting the connection process and resetting congestion control and loss recovery state, including resetting any pending timers.  Either packet indicates that the Initial was received but not processed.  Neither packet can be treated as an acknowledgment for the Initial. The client MAY however compute an RTT estimate to the server as the time period from when the first Initial was sent to when a Retry or a Version Negotiation packet is received.  The client MAY use this value to seed the RTT estimator for a subsequent connection attempt to the server. 6.5. </ins> When packet protection keys are discarded (see Section 4.9 of QUIC- TLS), all packets that were sent with those keys can no longer be acknowledged because their acknowledgements cannot be processed

Discussion:
Moves the "Retry and Version Negotiation" out of the "Crypto Retransmission Timeout" section in preparation for a redo of
Change:
not going to be included in a cryptographic computation.  This bucket is encoded in the message as a binary object.  This value is obtained by CBOR encoding the protected map and wrapping it in <del> a bstr object.  This wrapping allows for the encoding of the </del> <ins> a bstr object.  Senders SHOULD encode an empty protected map as a zero length binary object (it is shorter).  Recipients MUST accept both a zero length binary value and a zero length map encoded in the binary value.  The wrapping allows for the encoding of the </ins> protected map to be transported with a greater chance that it will not be altered in transit.  (Badly behaved intermediates could decode and re-encode, but this will result in a failure to verify

Discussion:
Add more intro text to algorithms Put in a note about the fact that a zero length map is not the preferred encoding for the protected field, but is a legal one.
Change:
METHOD = 0, 1, 2, or 3 (see fig-method-types). <del> SUITES_I - cipher suites which the Initiator supports in order of (decreasing) preference.  The list of supported cipher suites can be truncated at the end, as is detailed in the processing steps below and wrong-selected.  One of the supported cipher suites is selected.  The selected suite is the first suite in the SUITES_I CBOR array.  If a single supported cipher suite is conveyed, then that cipher suite is selected and SUITES_I is encoded as an int instead of an array. </del> <ins> SUITES_I - array of cipher suites which the Initiator supports in order of preference, starting with the most preferred and ending with the cipher suite selected for this session.  If the most preferred cipher suite is selected then SUITES_I is encoded as that cipher suite, i.e. as an int.  The processing steps are detailed below and in wrong-selected. </ins> G_X - the ephemeral public key of the Initiator

Discussion:
Addressing
NAME Please check if your comments are addressed.
Yes, especially in [1]. Thanks! [1] URL
-08 contained a definition of CREDx including an example when kid is used. -09 removed that example and replaces it with a RPK by value example. Now it seems like the most important use case is not well specified. This is the use case that leads to message2 being 45 bytes.
In addition the TOFU use case should likely also have a kid. Otherwise the UCCS has to be sent by value every time.
This is solved by just adding a 'kid' in the COSE_Key map
The document should say someting more about COSEKey. If IDCREDx = { 4 : keyidx } identifies a raw COSEKey, is that an error or is CREDx then the COSEKey wrapped in a UCCS without any parameters like sub?
SUITES_R is a name. The type needs to be defined and the table changed. This can be done in PR
The current definition of SUITESI is that the Initiator can chose any truncation of the list of supported cipher suites as long as the selected cipher suite is included. This works and allows the Initiator to give the Responder information about the full list. This is however a bit complex and has led to misunderstandings of the test vectors where several people thought the test vectors were wrong. i.e. the following are all valid I think we should simplify SUITESI by mandating that the last suite in the list is the selected. This makes SUITESI much easier to understand and lowers message size when an array is used. Giving the Responder info is not so important. CDDL
Maybe a recommendation that SUITES_R SHOULD contain all cipher suites that R supports.
Currently SUITESR : [ supported : 2 suite ] / suite We may keep that, or remove "supported" SUITESR : [ 2 suite ] / suite Alternatively, we may define SUITES_I : [ supported : 2* suite ] / suite Any preference?
They should be the same: or And then
This needs to be defined as a CDDL type. suites = [ 2* suite ] / suite See
Change:
certificates. The client MUST NOT accept a delegated credential unless the server's <del> end-entity certificate has the DelegationUsage extension. </del> <ins> end-entity certificate satisfies the following criteria: It has the DelegationUsage extension. It has the digitalSignature key usage enabled (see the Keyusage type in RFC5280), but has the keyEncipherment and dataEncipherment usages are disabled. </ins> 5.

Discussion:
Based on One of the design criteria for this standard is to isolate the TLS with the DC extension from other protocols. In this PR, I propose explicitly restricting the X.509 KeyUsage of the end-entity certificate. This change is made in the last commit: URL The two commits that proceed it don't actually change the semantics of the standard, but clean up the language a bit. If the KeyUsage change isn't adopted, we might consider merging the other two commits.
if it's not too painful, could you move this particular diff above all the others, I think I want to have some more discussion on this one. If its painful, we can just resolve this one first
Done, NAME
looks like i merged this as a result of merging a dependent PR accidentally. This is fine, we can just discuss this before I put up the next draft versions
Change:
the HTTP server responds with an HTTP error status as described in errors. <del> If a fatal error is encountered while processing an HTTP request, </del> <ins> If a fatal error is encountered while processing an HTTP response, </ins> the HTTP client... [TODO: Figure out what behavior is called for here.  An HTTP request should be sent that conveys the error.]

Discussion:
While implementing upload today, I also noticed some inconsistencies between the handling of reports in the leader during the upload protocol and the helper
Change:
registration in order to recover from a key compromise or proactively mitigate the impact of an unnoticed key compromise. <del> To change the key associate with an account, the client POSTs a key- change object with a "key" field containing a JWK representation of the new public key.  The JWS of this POST must have two signatures: one signature from the existing key on the account, and one signature from the new key that the client proposes to use.  This demonstrates that the client actually has control of the private key corresponding to the new public key.  The protected header must contain a JWK field containing the current account key. </del> <ins> To change the key associate with an account, the client sends a POST request containing a key-change object with the following fields: The JWS representation of the original key (i.e., the client's current account key) The JWS representation of the new key The JWS of this POST must have two signatures: one signature from the existing key on the account, and one signature from the new key that the client proposes to use.  This demonstrates that the client actually has control of the private key corresponding to the new public key.  The protected header must contain a JWK field containing the current account key. </ins> On receiving key-change request, the server MUST perform the following steps in addition to the typical JWS validation:

Discussion:
The current mechanism has a potential copy/paste vulnerability. Karthik proposed on the list: That is, you need the full matrix of "X signs over Y" -- "new/old", "new/new", "old/old", "old/new" -- so that both sides explicitly agree to the (old, new) pair. But the current design has only has "old/new" and "new/new". That raises a risk that if you got an "old/new" signature, you could copy/paste the "new/new" signature and get a valid request. As long as we have parallel signatures (cf. ), we need to have both the old and new keys in the payloads.
Change:
1. <del> 2. </del> <ins> Remote Attestation, as used in this document, is a process by which one entity (the "Attester") provides evidence about its identity and state to another remote entity (the "Relying Party"), which then assesses the Attester's trustworthiness for the Relying Party's own purposes. </ins> <del> The document defines the term "Remote Attestation" as follows: A process by which one entity (the "Attester") provides evidence about its identity and state to another remote entity (the "Relying Party"), which then assesses the Attester's trustworthiness for the Relying Party's own purposes. </del> <ins> 2. </ins> <del> This document then uses the following terms: </del> <ins> This document uses the following terms: </ins> Appraisal Policy for Evidence: A set of rules that direct how a verifier evaluates the validity of information about an Attester.

Discussion:
Removed incorrect text that said Remote Attestation was not defined in the doc. Moved Remote Attestation paragraph to the introduction section where I think it will (eventually) make sense in the context of introduction text. Signed-off-by: Dave Thaler
See comments in URL this term gets re-introduced here, without any annotation. The appraisal policy are the rules on how to test the evidence. Here, "Attestation" is the creation of the evidence Often people use the term "Attestation" to refer to the whole process. Suggestion that we should define this term somewhere, but maybe "Remote Attestation"? NAME FIDO has NONE-Attestation-Type, where there is no assessment. TCG would call this Implicit Attestation. URL NAME Let's take this to the WG, and maybe we can not get consensus on this term. NAME Charter says: "Remote attestation procedures (RATS) enable relying parties to establish a level of confidence in the trustworthiness of remote system components through the creation of attestation evidence by remote system components and a processing chain towards the relying party."
PR added a paragraph defining Remote Attestation, and PR does some additional cleanup.
Can we close this issue now that PR and PR are merged?
yes
Change:
entire certificate and the delegated credential, cannot. Each delegated credential is bound to a specific signature <del> algorithm.  This prevents them from being used with other, unintended, signature algorithms. </del> <ins> algorithm that may be used to sign the TLS handshake (RFC8446 section 4.2.3).  This prevents them from being used with other, perhaps unintended signature algorithms. </ins> 2.2.

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:
If DNS is misconfigured so that a client receives ESNI keys for a server which is not prepared to receive ESNI, then the server will <del> ignore the "encrypted_server_name" extension, as required by I- D.ietf-tls-tls13; Section 4.1.2.  If the servers does not require SNI, it will complete the handshake with its default certificate. Most likely, this will cause a certificate name mismatch and thus handshake failure.  Clients SHOULD not fall back to cleartext SNI, because that allows a network attacker to disclose the SNI.  They MAY attempt to use another server from the DNS results, if one is provided. </del> <ins> ignore the "encrypted_server_name" extension, as required by RFC8446; Section 4.1.2.  If the servers does not require SNI, it will complete the handshake with its default certificate.  Most likely, this will cause a certificate name mismatch and thus handshake failure. Clients SHOULD NOT fall back to cleartext SNI, because that allows a network attacker to disclose the SNI.  They MAY attempt to use another server from the DNS results, if one is provided. </ins> 6.2. A more serious problem is MITM proxies which do not support this <del> extension.  I-D.ietf-tls-tls13; Section 9.3 requires that such proxies remove any extensions they do not understand.  This will have one of two results when connecting to the client-facing server: </del> <ins> extension.  RFC8446; Section 9.3 requires that such proxies remove any extensions they do not understand.  This will have one of two results when connecting to the client-facing server: </ins> The handshake will fail if the client-facing server requires SNI.

Discussion:
Replace "It only affects connection routing, server certificate selection, and client certificate verification." with "It may affect connection routing, server certificate selection, and client certificate verification."
URL It is relative to "This design has no impact on application layer protocol negotiation.", so "only" is more explicit.
This was fixed in and I forgot to close.
Change:
approach (not validating the names presented in the SubjectAlternativeName field of the certificate) as long as the IP address of the Encrypted Resolver does not differ from the IP address <del> of the Unencrypted Resolver, and that IP address is a private address (such as those defined in RFC1918).  This approach can be used for DoT or DoH. If the IP addresses of the Encrypted and Unencrypted Resolvers are not the same, or the shared IP address is not a private IP address, the client MUST NOT use the Encrypted Resolver opportunistically. </del> <ins> of the Unencrypted Resolver.  This approach can be used for any encrypted DNS protocol that uses TLS. </ins> 5.

Discussion:
The document was inconsistent, with the authenticated section saying same IP addresses MAY use opportunistic, but the opportunistic section saying the same IP address exception was for private IP addresses only.
Forgot to mention this is to address issue
From Eliot Lear: Can you explain the following statement? and that IP address is a private address (such as those defined in [RFC1918] I ask because it appears that you are using private addresses as some sort of security property. I recommend against that, not least of which is that end systems that are likely to deploy this stuff will have a wide ranging mishmosh of addressing plans, and of course, private network addresses don’t really have any positive security properties to speak of. The only aspect I can see is that one really has to be quite careful of including private network addresses in certificates. Of course, public trust anchors won’t allow it, but even private ones will have some difficulty. Your average bank might have multiple overlapping zones of trust - it’s a pretty hairy scene.
The intent of that section is to say that "if you were going to send this local IP address unencrypted traffic anyway, using encryption to that same IP address is a net improvement to the threat model." It certainly was not meant to imply that private addresses could be verified via the TLS cert SAN mechanism used for public addresses. I can try to rephrase this section to be more accurate. Please comment again if I missed the point.
In reviewing the opportunistic section, I see what you mean Eliot. The need to use "private IP" as a feature is not necessary since same-IP opportunistic discovery is permitted whether the address is private or not. However, the draft conflicted on that point. I have a PR to remove the local IP address as a decision branch and make the draft consistent.
With the PR merged, I am closing this issue.
Change:
Path validation is required so that endpoints validate paths before use to avoid address spoofing attacks.  Path validation takes at least one RTT and congestion control will also be reset after path <del> migration.  Therefore migration usually has a performance impact. </del> <ins> migration.  Therefore, migration usually has a performance impact. </ins> QUIC probing packets, which can be sent on multiple paths at once, are used to perform address validation as well as measure path

Discussion:
All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions.
Change:
Connection establishment is divided into two top-level steps: Candidate Gathering, to identify the paths, protocols, and endpoints <del> to use, and Candidate Racing, in which the necessary protocol handshakes are conducted so that the transport system can select which set to use.  This document structures candidates for racing as a tree. </del> <ins> to use, and Candidate Racing (see Section 4.2.2 of I-D.ietf-taps- arch), in which the necessary protocol handshakes are conducted so that the transport system can select which set to use.  This document structures candidates for racing as a tree. </ins> The most simple example of this process might involve identifying the single IP address to which the implementation wishes to connect,

Discussion:
Oh yes, and it IS editorial ! :-D
Is "racing" really the right term? It might be a term of art that applies even in cases like this, but many of the relationships between different branches in the tree are based on preference rather than lowest latency. I don't feel strongly about this, but I don't know if this has been brought up yet, so I figured I'd mention it.
I agree that it may seem a bit misleading, but I think it's ok - it's just the word we use for it, and the term and how we use it is quite clearly defined in the Architecture draft, section 4.2.2. Just my 2c
I like "racing" - it's just a term....
Racing is defined in the architecture document; add a reference back there.
Thanks for fixing this!
Change:
including those caused by intermediaries such as a DNS proxy running on a home router. <del> "not_before" and "not_after" fields represent the validity period of the published ESNI keys.  Clients MUST NOT use ESNI keys that was covered by an invalid checksum or beyond the published period.  If none of the ESNI keys values are acceptable, the client SHOULD behave as if no ESNI records were found. Servers SHOULD set the Resource Record TTL small enough so that the record gets discarded by the cache before the ESNI keys reach the end of their validity period.  Note that servers MAY need to retain the decryption key for some time after "not_after", and will need to consider clock skew, internal caches and the like, when selecting the "not_before" and "not_after" values. Client MAY cache the ESNIRecord values for a particular domain based on the TTL of the Resource Record, but SHOULD NOT cache them based on the not_after value of the ESNIKeys structure, to allow servers to rotate the keys often and improve forward secrecy. </del> Note that the length of the ESNIRecord structure MUST NOT exceed 2^16 - 1, as the RDLENGTH is only 16 bits RFC1035.

Discussion:
We now have a proper retry mechanism, so we don't need to prevent clients to connect using expired keys anymore.
NAME notes that the notbefore and notafter fields are there and described, but not really part of the operational notes. Having something there that talks about these, particularly as it relates to clock skew, would be valuable.
(My ~monthly login into URL - this'd be better on the TLS WG list, and I will send mail on this sometime but anyway...) The not-before and not-after fields are a mistake. Same as turned out true for x.509. I was just doing testing where FF nightly barfed on ESNIKeys I'd published for only that non-reason. (There is no overall security win in so-doing, in general.) Creating a tangle between the cadence at which one updates DNS, the ESNIKeys-internal "lifetime" of a key, the DNS TTL and server-state is basically just pointless nonsense. Let's delete those fields from ESNIKeys before we're done and just rely on DNS for what it already does.
Now that has been merged, I agree that there is less need for notbefore and notafter fields. Previously, a client using an expired key led to connection failure, and therefore having these fields were necessary.
Fixed by removing these fields with .
Thank you for the PR. LGTM