jiebi/CodeConvo huggingface dataset:
Change:
the byte limit to account for the smaller 8 byte overhead of UDP compared to the 20 byte overhead for TCP. <ins> Prior to validating the client's address, the server can be further limited by the anti-amplification limit as specified in Section 8.1 of QUIC-TRANSPORT.  Though the anti-amplification limit can prevent the congestion window from being fully utilized and therefore slow down the increase in congestion window, it does not directly affect the congestion window. </ins> The minimum congestion window is the smallest value the congestion window can decrease to as a response to loss, ECN-CE, or persistent congestion.  The RECOMMENDED value is 2 * max_datagram_size.

Discussion:
Clarifies the impact of the anti-amplification factor on congestion control. Part of
When the client has a large first flight (post-quantum, or 0-RTT), it can send 10 packets at once. But that does not mean that the server can immediately send as much as 3x it receives in response, because that is above the INITCWND - the initial assumption about the network capacity. Things to be considered here are: Server cannot rely on CC until the client's address is validated, because an attacker might spoof Initial ACKs. At the very least, server needs to send one Initial in response to every client Initial packet not containing ACKs, otherwise the handshake might fail when there is heavy loss. Based on this observation, to me it seems that the easiest way of going forward would be to state that the amplification limit changes from 3x to 1x once the amount of data being sent by the server reaches INITCWND. Disclaimer: this issue popped up while trying to find out a response to NAME claim that quicly sends 3x that is above INITCWND, when the client sends a large amount of 0-RTT data. He's correct, and NAME and I think that this is a spec-issue.
Just to clarify, only an on-path attacker can do this, right?
I agree it should be limited to INITCWND. Here's how I read(and intended to write) the text: 1) Congestion control always applies, because I don't know of anywhere we say otherwise. 2) In addition, prior to address validation, the amplification limit of 3x also applies on the server side. Init CWND section: URL
NAME An off-path attacker can do that. An attacker can easily guess the packet number that the server uses, and spoof an ACK without actually receiving a packet from the server. Note also that there is no guarantee that there would be enough entropy in server-generated CID, even though a server can generate CIDs in such a manner. That's why we postpone the validation of the path until the server receives a Handshake packet. NAME I think I agree with you that the limit can be defined as .
Thanks NAME PTAL at PR and see if that clarifies this issue or if something else is necessary.

At the editor's meeting, we concluded that the pseudocode did not represent the current text about re-arming the PTO alarm. I merged the first PR because I think it's a nice clarification and I'll send out a PR for the pseudocode.
Thank you for the quick PR. I've stated my slight preference, but the text looks already :+1: to me.
Change:
query domain name's canonicalized form.  That is, if a client queries example.com, the ESNI Resource Record might be: <del> The "checksum" field provides protection against transmission errors, including those caused by intermediaries such as a DNS proxy running on a home router. </del> <ins> In the event that ESNIKeys is corrupt in transit or otherwise invalid, servers will initiate the retry mechanism described in server-behavior and deliver valid ESNIKeys to clients. </ins> Note that the length of the ESNIRecord structure MUST NOT exceed 2^16 - 1, as the RDLENGTH is only 16 bits RFC1035.

Discussion:
The checksum seems to add little value with the retry mechanism and record_digest. I think we should remove it. See for some context.
The I-D says: "recorddigest : A cryptographic hash of the ESNIKeys structure from which the ESNI key was obtained, i.e., from the first byte of "checksum" to the end of the structure. This hash is computed using the hash function associated with suite." From looking at the NSS code it appears that the recorddigest input is actually the entire ESNIKeys (after base64 decode) including the version and checksum. Is that correct? IOW, does the following also produce the right value (for CF and sha256)? `
proposes removing the checksum, which should clear this up.
Closing since landed. NAME please re-open if this is still an issue!
The hash used in the extension should use the same hash inputs as the checksum. The difference here just makes using this harder.
I support the change, if that makes people feel more comfortable about having the checksum field in ESNIKeys.
I'm not opposed, but it doesn't help as much as you might think, because you need to compute the label with the cipher hash and not (necessarily) with SHA-256.
So, if you take my suggestion in (which I know NAME doesn't like, but we simply disagree about that), then you can identify the ESNI using a truncated hash that is calculated using the cipher hash because it only appears in the context of a handshake. But that just suggests that this is either not-helpful because we chose not to do anything in , or it is not necessary because we did. I'm OK closing this on that basis.
Checksum is now gone. Closing this issue. NAME thanks for filing it!
I agree that we can now and should make this simplification. The PR looks good to me.
Change:
As a consequence of this configuration, Oblivious HTTP prevents linkability described above.  Informally, this means: <del> Requests and responses are known only to and Target Resources, plus that possess the corresponding response encapsulation key and HPKE keying material.  In particular, the knows the origin and destination of an and Response, yet does not know the decrypted contents.  Likewise, learn only the and the decrypted request.  No entity other than the can see the plaintext request and response and can attribute them to the . </del> <ins> Requests and responses are known only to and .  In particular, the knows the origin and destination of an and Response, yet does not know the decrypted contents.  Likewise, learn only the and the decrypted request.  No entity other than the can see the plaintext request and response and can attribute them to the . </ins> <del> Targets cannot link requests from the same in the absence of unique per- keys. </del> <ins> Oblivous Gateway Resources, and therefore Target Resources, cannot link requests from the same in the absence of unique per- keys. </ins> Traffic analysis that might affect these properties are outside the scope of this document; see ta.

Discussion:
This change tries to emphasize that OHTTP is a protocol between client, relay, and gateway, and that the target is sort of ancillary to the whole thing. It further clarifies that the relay should not act as an open proxy when it's operated by an entity that is separate from the target server.
This works for me. We can merge this and then I want to take another pass at the other PR.Thanks NAME -- couple nits, otherwise lgtm.LGTM
Change:
Mitigates: <del> 4.3.20. </del> <ins> 4.3.21. </ins> Both the manifest and any data extracted from it MUST be held immutable between its authenticity verification (time of check) and

Discussion:
Clarified several points: Remote secure clocks require authentication. This was assumed when using the "correctness guarantees" however that was not sufficiently clear. Risks associated with using a flawed clock for manifest expiry. Secure clock can be used for key expiry. Risk of flawed clock for key expiry is identical to not having key rotation.
Ben Kaduk wrote:
We might also discuss the risks when a device believes that it possesses a source of secure time but the timesource is actually flawed.
Change:
in signature-algorithms.  The following values SHALL be marked as "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519. <del> Finally, this document obsoletes the TLS HashAlgorithm Registry and the TLS SignatureAlgorithm Registry, both originally created in RFC5246.  IANA [SHALL update/has updated] the TLS HashAlgorithm Registry to list values 7-223 as "Reserved" and the TLS SignatureAlgorithm Registry to list values 4-223 as "Reserved". </del>

Discussion:
Is it strictly necessary to include the following in the TLS1.3 draft: Finally, this document obsoletes the TLS HashAlgorithm Registry and the TLS SignatureAlgorithm Registry, both originally created in [RFC5246]. IANA [SHALL update/has updated] the TLS HashAlgorithm Registry to list values 7-223 as “Reserved” and the TLS SignatureAlgorithm Registry to list values 4-223 as “Reserved”. If this text wasn't in the TLS1.3 draft everything would be fine right? If that's the case, then this text from s10 should be moved to .
Sorry, I'm not following the issue. I'm happy to move it out, though.
It kind of seems like the move of registries should be done atomically, which is ~guaranteed by doing it in the same document, but could still be done atomically if the two documents are advanced at the same time. (I, like ekr, am not really clear on what the issue is, though.)
I guess I see reserving the remaining values as essentially slamming the door on future assignments. Was that the intent? spt
I should have also added that URL already includes a paragraph indicating that Compression Method Identifiers, HashAlgorithm, and SignatureAlgorithm are obsoleted by TLS1.3; adds a note to the registries indicating as much. spt
My understanding was that yes, "don't look here, go look over there" was the idea. Any new allocation would need to go in the SignatureScheme registry, regardless of whether it also ended up in the HashAlgorithm or SignatureAlgorithm registry as well for someone's convenience. Since you have to go to the new registry anyway, it doesn't seem like there would be value in also adding it to the old/deprecated registry.
Okay that makes sense and it explains why the values in the Compression Method Identifiers isn’t also “reserved”. I guess I’m off the mind that this para could safely be move to the IANA draft.
Specially move the text to s13 of .
Change:
The string "tls-sni-02" A random value that uniquely identifies the challenge.  This value <del> MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). </del> <ins> MUST have at least 128 bits of entropy.  It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). </ins> A client responds to this challenge by constructing a self-signed certificate which the client MUST provision at the domain name

Discussion:
Per feedback from Zach Shepherd[0] on the mailing list the justification for the 128 bits of required token entropy from section 8.2 is at odds with the actual rationale (as I understand it). This commit updates the justification for the entropy requirement to not mention being secret from an attacker, but instead not predictable by a naive challenge response server that would complete challenges without having been a party to the authz/chal creation.
It seems like whatever change is made should be applied to sections 8.2, 8.3, and 8.4.
Based on zjs' feedback, I think it makes more sense for the individual token fields to just say "MUST have 128 bits", and explain why in one place in the Security Considerations section.
NAME NAME Updated. Thanks for the feedback!
Change:
If a server receives a ClientHello at any other time, it MUST send a fatal "unexpected_message" alert and close the connection. <ins> If a server established a TLS session at a previous version of the protocol and receives a TLS 1.3 ClientHello in a renegotiation, it MUST retain the previous protocol version.  In particular, it MUST NOT negotiate TLS 1.3.  A client that receives a TLS 1.3 ServerHello in an established session MUST send a fatal "protocol_version" alert and close the connection. </ins> Structure of this message: %%% Key Exchange Messages

Discussion:
the renegotiation mechanism from TLSv1.2 and earlier is deprecated, that deprecation extends to the ability to renegotiate existing TLSv1.2 (or earlier) session to TLSv1.3
Sorry, but I just realized you can't do this. You need to prohibit negotiating back up to 1.3, but the client has to be able to offer 1.3. Here's the Bugzilla thread on this URL
so the client MAY send a TLSv1.3 Client Hello in a TLSv1.2 session, but server MUST NOT negotiate TLSv1.3 then?
How about this?
OpenSSL derived implementations don't even allow you to switch versions on renego at all because that would be insane. We do send the higher ClientHello version for the reasons EKR pointed out, but the ServerHello version must match. I would actually argue that it is fair game to assume version-related things are implicitly forked and locked (a 1.1 session implicitly cannot be resumed at 1.2, etc.), but the spec should be much clearer on this, so saying it explicitly now is a good idea.
Yes. , Hubert Kario EMAIL wrote:
I agree, resuming sessions must be at the same version and text saying so is a good idea.
NAME This is actually about negotiating at TLS 1.2 and then renegotiating to TLS 1.3. It's not clear how you would even manage to resume a TLS 1.2 session at TLS 1.3 or vice versa, but explicit text to this effect would be good. It has certainly historically been a mess.
OK, that should fix all the comments.
Merged. NAME please send me a PR adding yourself to Contributors
NAME here it is:
Change:
DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the HTTP path alone, since an attacker could modify the "dohpath" <del> parameter. </del> <ins> parameter.  For example, if a DoH resolver provides provides a filtering service for one URI path, and a non-filtered service for another URI path, an attacker could select which of these services is used by modifying the "dohpath" parameter.  These attacks can be mitigated by providing separate resolver IP addresses or hostnames. </ins> While the IP address of the Unencrypted Resolver is often provisioned over insecure mechanisms, it can also be provisioned securely, such

Discussion:
NAME please review!!
What does this mean? I'm struggling to work out what this might mean for someone operating a DoH server. Does this mean that rewriting "/doh{?dns}" to "/~attacker/abcdef{dns}URL" is considered something that the DoH resolver needs to identify and recover from? Or, is this more narrow in that a DoH server cannot offer two different services on a referred endpoint with different treatment policies? In the former case, the attacker can deny service by modifying the "dohpath". In the latter case, the attacker gets to choose which of the two services is used. I think that you want to lump the former under the general DoS risk. But the latter implies something very specific in terms of action on the part of the resolver operator. They cannot offer more than one DoH service on the same IP address (where DDR doesn't give them any virtual hosting capabilities via SNI) or hostname (where it does). You might need to be a lot clearer about that.
This is about the latter case — if the resolver offers two very different services on different paths, the attacker would get to choose which service is used. That doesn't mean you can't offer different services on the same resolver IP address, but something else would need to be different other than the path — like, for DDR clients, they'll be using the IP address, but some client that was configured with a specific service might use a specific hostname too.
This is from this: URL
See also: URL
NAME please see
Thanks NAME this is an improvement.LGTM
Change:
The date of last update to the registration. <ins> The entity that is responsible for the definition of the registration. </ins> Contact details for the registrant. Supplementary notes about the registration.

Discussion:
At NAME suggestion this adds a "change controller" field to registries and splits between a change controller (IETF) and contact (QUIC WG). Not really sure if this is worth a design label...
Section 22.1.1: It is quite common that one may want to separate who has the change control over an registration entry vs who is the contact. Change control can often be assigned to an organization rather than an individual while a contact information may be an individual or a specific contact address for the organization. Contact information has a tendency to get stale, and in many case the contact if a person may no longer represent the organization that made the registration. Thus, my suggestion would be to add a separation between contact and change controller. In fact just for the registration in the Transport doc it makes sense to make the change controller "IETF" and have the contact be "QUIC WG".
This also applies to permanent registrations in Section 22.1.4
NAME does the PR address your issue?
Change looks good and implements what I proposed.
Labeling as "editorial" based on
Change:
0xFEFF are reserved for private use. Indicates support of the corresponding finite field group, defined <del> in I-D.ietf-tls-negotiated-ff-dhe.  Values 0x01FC through 0x01FF are reserved for private use. </del> <ins> in RFC7919.  Values 0x01FC through 0x01FF are reserved for private use. </ins> Items in named_group_list are ordered according to the client's preferences (most preferred choice first).

Discussion:
draft-ietf-tls-negotiated-ff-dhe is now RFC 7919. draft-mattsson-tls-ecdhe-psk-aead is now draft-ietf-tls-ecdhe-psk-aead.
Do we even need a reference to draft-ietf-tls-ecdhe-psk-aead with the new negotiation syntax?
NAME I removed it from the reference section. It was used in previous versions. But it is no longer referenced to by any text in the spec since version 15.
Change:
can be accessed in a Link header with link relation "terms-of- service".  As noted above, the client may indicate its agreement with these terms by updating its registration to include the "agreement" <del> field, with the terms URI as its value. </del> <ins> field, with the terms URI as its value.  When these terms change in a way that requires an agreement update, the server MUST use a different URI in the Link header. </ins> If the client wishes to update this information in the future, it sends a POST request with updated information to the registration

Discussion:
I'm not sure whether we should add something like:
I think "in a way that requires an agreement update" as you've written is clear enough. Users won't need to re-agree if just fixing a typographical error.
Change:
field name might occur for shorter values more quickly or with higher probability than for longer values. <del> 7.4. </del> <ins> 7.1.3. </ins> Implementations can also choose to protect sensitive fields by not compressing them and instead encoding their value as literals.

Discussion:
Magnus Nystrom : not be able (based on no current known attack against static Huffman encodings) to mount the previously described "probing" attack? If so, adding a sentence at the end of the section along the lines of "Thus, the previously mentioned probing attack is not known to be applicable for any fields where static Huffman encoding is used."
This section is not related to the probing attack. I think some of the confusion here is lost formatting when importing from RFC 7541. The TOC should be:
Change:
end-to-end cryptographic context.  Packet numbers are therefore not part of the wire image that is useful to on-path observers. <del> 2.7. </del> <ins> 2.8. </ins> Version negotiation is not protected, given the used protection mechanism can change with the version.  However, the choices provided

Discussion:
also to address issue
Copying from URL There's no requirement that servers use a particular UDP port for HTTP/QUIC or any other QUIC traffic. Using Alt-Svc, the server is able to pick and advertise any port number and a compliant client will handle it just fine. That's already the case, and isn't part of this issue. updates the HTTP draft to highlight this, increasing the odds that implementations will test and support that case. This issue is to track that it might actually be desirable from a privacy standpoint for servers to pick arbitrary port numbers and perhaps even rotate them periodically (though that requires coordination with their Alt-Svc advertisements and lifetimes, which could be challenging) in order to make it more difficult for a network observer to classify traffic (and therefore more difficult to ossify). On the other hand, as we're wrestling with in each of these privacy/manageability debates, removing easy network visibility into the likely protocol by using arbitrary port numbers means that middleboxes will probably resort to other means of attempting to identify protocols and potentially doing it badly, which could result in even worse ossification. (E.g. indexing into the TLS ClientHello to find the ALPN list, then panicking on a different handshake protocol.) There's further discussion on the original issue, but this belongs in the ops drafts, not the protocol drafts.
this kind-of-but-not-really-duplicates , which I'll go ahead and close.
Actually, it's an exact duplicate, given that it points to the same issue. ;-) My bad.
NAME can you check if PR addresses this issue sufficiently? At least for the applicability doc...
Now also PR for the manageability statement.
and are a (ready for -03) treatment of this; however, we should consider if we want to say more, e.g. such as general guidance / recommendations for using ALPN in QUIC mappings, for instance? Keeping this open to track.
created new issue for ALPN
Change:
The formal definition of a Group in MLS is the set of clients that have knowledge of the shared group secret established in the group key establishment phase of the protocol and have contributed to it. <del> Until a Member has contributed to the group secret, other members cannot assume they are a member of the group. </del> <ins> Until a Member has been added to the group and contributed to the group secret in a manner verifiable by other members of the group, other members cannot assume that the Member is a member of the group. </ins> 2.2.

Discussion:
Minor corrections throughout from joint edits by NAME NAME and NAME Some description text added.
In the section "Groups, Members, and Clients", the definition of a group in MLS is the set of clients that have knowledge of the shared group key, which is established in the group key exchange. The spec then goes on to say that "Until a Member has contributed to the group secret, other members cannot assume she is a member of the group." This phrasing of what constitutes a group member is quite weak and does not actually reflect the security properties of the underlying group key exchange. If a member has not contributed to the shared group secret, she cannot be considered a member of the group, as 1) she should not be able to learn the group key (without acting adversarially outside of the protocol), and 2) other members cannot verify her membership Instead, I would rephrase this description of a member/non-member to say something stronger, like "Until a Member has been added to the group by another member---thereby requiring that she contributes to the group secret in this process in such a way that is verifiable to other group members--she will not be able to participate as a member of the group."
Good idea. An edit on this has been added to PR .
I might be missing something here: Can't a party be added to a group (thus learning the group secret) and from that point never contribute to the shared group secret? That party would still be able to encrypt and decrypt application messages.
Hi NAME could you please check the current document and propose a new phrasing if needed? Thanks : )
NAME confirmed to me offline that this issue was addressed in
Modulo a few nits that can be fixed post-merge, this looks quite good Thanks to you three for the PR!