jiebi/CodeConvo huggingface dataset:
Change:
"psk_secret" to 0. Construct an MLSPlaintext object containing the Commit object. <del> Use the "commit_secret" and the "psk_secret" to advance the key schedule and compute the "confirmation_tag" value in the MLSPlaintext.  Sign the MLSPlaintext using the current epoch's GroupContext as context. </del> <ins> Sign the MLSPlaintext using the current epoch's GroupContext as context.  Use the signature, the "commit_secret" and the "psk_secret" to advance the key schedule and compute the "confirmation_tag" value in the MLSPlaintext. </ins> Update the tree in the provisional state by applying the direct path

Discussion:
As discussed in the mailing list, not having the signature contribute to the new epoch's key schedule leads to a one-off effect where parties stay in sync (with respect to keys) for one more epoch, before inevitably go out of sync. This pull request addresses this issue by including the signature in the confirmed transcript hash rather than the interim transcript hash. See the mailing list for a security consideration of this change. Credit: This pull request was primarily authored by Marta Mularczk; I'm just posting it here for administrative reasons.
Change:
4.1. Streams are meaningful only to the application; since stream <del> information is carried inside QUIC's encryption boundary, no information about the stream(s) whose frames are carried by a given packet is visible to the network.  Therefore stream multiplexing is not intended to be used for differentiating streams in terms of network treatment.  Application traffic requiring different network treatment should therefore be carried over different five-tuples (i.e.  multiple QUIC connections).  Given QUIC's ability to send application data in the first RTT of a connection (if a previous connection to the same host has been successfully established to provide the necessary credentials), the cost of establishing another connection is extremely low. </del> <ins> information is carried inside QUIC's encryption boundary, a given packet exposes no information about which stream(s) are carried within the packet.  Therefore, stream multiplexing is not intended to be used for differentiating streams in terms of network treatment. Application traffic requiring different network treatment should therefore be carried over different five-tuples (i.e.  multiple QUIC connections).  Given QUIC's ability to send application data in the first RTT of a connection (if a previous connection to the same host has been successfully established to provide the necessary credentials), the cost of establishing another connection is extremely low. </ins> 4.2.

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:
record for that domain. Clients obtain these records by querying DNS for ESNI-enabled server <del> domains.  Thus, servers operating in Split Mode SHOULD have DNS configured to return the same A (or AAAA) record for all ESNI-enabled servers they service.  This yields an anonymity set of cardinality equal to the number of ESNI-enabled server domains supported by a given client-facing server.  Thus, even with SNI encryption, an attacker which can enumerate the set of ESNI-enabled domains supported by a client-facing server can guess the correct SNI with probability at least 1/K, where K is the size of this ESNI-enabled server anonymity set.  This probability may be increased via traffic analysis or other mechanisms. </del> <ins> domains.  Clients may initiate these queries in parallel alongside normal A or AAAA queries, and SHOULD block TLS handshakes until they complete, perhaps by timing out. Servers operating in Split Mode SHOULD have DNS configured to return the same A (or AAAA) record for all ESNI-enabled servers they service.  This yields an anonymity set of cardinality equal to the number of ESNI-enabled server domains supported by a given client- facing server.  Thus, even with SNI encryption, an attacker which can enumerate the set of ESNI-enabled domains supported by a client- facing server can guess the correct SNI with probability at least 1/ K, where K is the size of this ESNI-enabled server anonymity set. This probability may be increased via traffic analysis or other mechanisms. </ins> The "checksum" field provides protection against transmission errors, including those caused by intermediaries such as a DNS proxy running

Discussion:
NAME please have a look!
The order of DNS queries may matter in systems that use Happy Eyeballs. Also, should TLS connections block until ESNI key queries come back? What if they never come back?
can you elaborate on what you're thinking about wrt he? (assuming the URL plan is off the table)
Basically addressed in .
Change:
where ESNIContents is as specified below and Hash is the hash function associated with the HKDF instantiation.  The salt argument for HKDF-Extract is a string consisting of Hash.length bytes set to <del> zeros. </del> <ins> zeros.  For a client's first ClientHello, KeyLabel = "esni key" and IVLabel = "esni iv", whereas for a client's second ClientHello, sent in response to a HelloRetryRequest, KeyLabel = "hrr esni key" and IVLabel = "hrr esni iv".  (This label variance is done to prevent nonce re-use since the client's ESNI key share, and thus the value of Zx, does not change across ClientHello retries.) [[TODO: label swapping fixes a bug in the spec, though this may not be the best way to deal with HRR.  See https://github.com/tlswg/ draft-ietf-tls-esni/issues/121 and https://github.com/tlswg/draft- ietf-tls-esni/pull/170 for more details.]] </ins> The client then creates a ClientESNIInner structure:

Discussion:
Since the client's ESNI key share doesn't change across CHs in response to a HRR, the same AEAD IV would be used to encrypt/decrypt two different messages. This is an attempt to fix that, while also specifying the server-side HRR behavior. (Basically, check that the ESNI contents have not changed.)
Nice catch, Would it make more sense to instead use the KeyShare as a salt in the HKDF?
Or you could include the handshake transcript up to, but not including, the ClientHello. That is the empty string before HRR< but something else after.
That is a little iffy with cookie-only HelloRetryRequests. Those don't change the ClientHello key shares list, so the client would derive the same key + nonce pair. The client would also use the same plaintext so it's fine, but it seems an unnecessarily fragility.
Agreed. I think I prefer the "new DH" version.
Thank you for the changes! LGTM.
Change:
within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams. <ins> A client could attempt to exhaust resources by opening too many WebTransport sessions at once.  In cases when the client is untrusted, the user agent SHOULD limit the number of outgoing sessions the client can open. </ins> 8. 8.1.

Discussion:
Porting URL originally posted to W3C WT NAME New connections should be throttled to avoid being a DoS vector. Maybe we will just have some language in the standard to permit and encourage throttling, and leave the details to browsers.
Shouldn't the throttling be performed at the W3C layer? If throttling happens, should the W3C API let the caller know?
I think this is a back-to-front way of suggesting that WebTransport include something like the guidance in URL (which I found , linked from URL
Oh thanks for finding that. I'm supportive of adding something like that.
I'm actually not sure that the specific requirement in WebSocket spec is useful, compared to just recommending throttling (or other forms of resource limits) in general.
The WebSocket throttling in RFC6455 requires you to implement it close to the socket layer (in particular, after DNS lookup), which is messy in practice. I think it may be sufficient to leave the details of the throttling to the implementation. If we want to ensure it is interoperable, a per-network-partitiion delay based on the number of pending and recently-failed connections should be sufficient.
So given that this is over HTTP/3, what is the anticipated throttling? Is it really just trying to tell HTTP clients to not make lots of requests? Is WebTransport sufficiently more expensive than other types of requests? I'm struggling to see language we would include here that is needed over language we have in QUIC or HTTP/3 already
Generally a browser will only make one HTTP/3 connection per server, regardless of how many resources the page requests. So servers don't need to worry about a well-behaved browser initiating large numbers of simultaneous QUIC handshakes. However, when WebTransport connections are not pooled, it is valid to make several at the same time. If there were no restrictions, a badly-behaved web page could request thousands of WebTransport connections simultaneously, DoSing the server.
Thanks Adam. I think phrasing thing as a design deviation from HTTP/3's recommendation to use one connection is good idea.
From what I can read from this discussion, there isn't that much in terms of design here, and this mostly requires writing up that throttling is up to the implementation.
Change:
NODATA NOERROR NOTIMP <ins> NS </ins> NSEC NSEC3 NXDOMAIN

Discussion:
Agree with the first one, although I don't care which way it comes out from the RFC Editor. For the second one, I have changed the wording to 'An authoritative server is named in the NS ("name server") record in a zone.' We don't need to stray into which zone has authoritative data; the double use of "authoritative" will confuse the reader without helping with the terminology.
l 179, s/octets which/octets that. This has been changed to violate the that/which conventions of the RFC Editor. l844 (new) the authoritative name server is named in the parent zone but is not authoritative data there (NS is authoritative in the child). This is discussed elsewhere in the document, and I find this addition confusing. I won't hold up pver either of these. The rest looks ok.
Change:
agree on a good set of facets that can be used to compare naming systems.  For example, other facets might include "protocol to update data in a name", "privacy of names", and "privacy of data <del> associated with names", but those do not not have a clear definitions as the ones listed above.  The list here is chosen because it helps describe the DNS and naming systems similar to the DNS. </del> <ins> associated with names", but those are not as well-defined as the ones listed above.  The list here is chosen because it helps describe the DNS and naming systems similar to the DNS. </ins> An ordered list of one or more labels.

Discussion:
Split into two pairs of commits (each first changing content and then line lengths) for easy partial acceptance, should that be desired: Improve grammar and diction Be consistent about ordering domain name labels from the root The second pair attempts to provide a consistent treatment of "domain name" as an abstract sequence of labels in directed graph order starting at the root, while maintaining clarity about wire, presentation, and common display formats rendering domain names in reverse.
Change:
When resuming via a PSK with an appropriate ticket (i.e., one with the "allow_early_data" flag), clients can also send data on their first flight ("early data").  This data is encrypted solely under <del> keys derived using the PSK as the static secret.  As shown in tls- 0-rtt, the Zero-RTT data is just added to the 1-RTT handshake in the first flight, the rest of the handshake uses the same messages. </del> <ins> keys derived using the first offered PSK as the static secret.  As shown in tls-0-rtt, the Zero-RTT data is just added to the 1-RTT handshake in the first flight, the rest of the handshake uses the same messages. </ins> [[OPEN ISSUE: Should it be possible to combine 0-RTT with the server authenticating via a signature https://github.com/tlswg/tls13-spec/

Discussion:
I would actually much rather we only offer one PSK identity since TLS 1.2 was perfectly fine offering just one and resumption has no use for offering multiple, but I suspect I will lose that fight. Absent that, at least make the protocol well-defined. Unlike both TLS 1.2 resumption and TLS 1.2 PSK, TLS 1.3 increases the state space and allows clients to offer multiple PSK identities. This mostly works, but 0-RTT presumes that only one is offered. Define 0-RTT to presume the first identity is selected and clarify that other shapes are possible due to the increased state space.
Change:
The format should allow implementations to specify additional important information in addition to the bare timestamp.  This is <del> done by allowing implementations to include an informative suffix at the end with as many tags as required, each with a key and value separated by an equals sign.  The value can be a hyphen delimited list of multiple values. </del> <ins> done by defining , each with a and a separated by an equals sign, and allowing implementations to include an informative at the end with as many tags as required.  The value of a tag can be a hyphen delimited list of multiple values. </ins> In case a key is repeated or conflicted, implementations MUST give precedence to whichever value is positioned first. 3.2. <del> Since the suffix can include all sorts of additional information, different standards bodies/organizations need a way to identify which part adheres to their standards.  For this, all information needs to be namespaced.  Each key is therefore divided into two hyphen- separated sections: the namespace and the key.  For example, the calendar as defined by the Unicode consortium could be included as </del> <ins> Since tags can include all sorts of additional information, different standards bodies/organizations need a way to identify which part adheres to their standards.  For this, all information needs to be namespaced.  Each key is therefore divided into two hyphen-separated sections: the namespace and the key.  For example, the calendar as defined by the Unicode consortium could be included as </ins> "u-ca=<value>". All single-character namespaces are reserved for BCP47 extensions

Discussion:
I looked through the inline comments as well. Should we file issues for all of these?
I think we should have a quick check if we can resolve any of these between us, and then make issues. Grüße, Carsten
(Many of the comments are really editorial. E.g., if you have a “BCP47 extensions registry” in mind, we can simply point to that; I just couldn’t find that.) I think I’ll submit the -01 now anyway, so we do have a new version to look at for the interim. Grüße, Carsten
Perfect, thanks. I'll try to see how many of the comments can be trivially resolved.
Please confirm -01; we can submit a -02 quickly after that (I-D deadline 2021-10-25!).
-01 is published o/
Perfect, thanks for the changes! They look great, and I apologize for the issues especially with the references, Metanorma was not making my life any easier.
Change:
identifier-validation-challenges describes a set of challenges for domain name validation. <ins> 7.1.5. An ACME challenge object represents a server's offer to validate a client's possession of an identifier in a specific way.  Unlike the other objects listed above, there is not a single standard structure for a challenge object.  The contents of a challenge object depend on the validation method being used.  The general structure of challenge objects and an initial set of validation methods are described in identifier-validation-challenges. </ins> 7.2. Before sending a POST request to the server, an ACME client needs to

Discussion:
As suggested by Felipe Gasper
NAME fixed. Note, also standardized on "validation method" (vs. "mechanism"). Hello, I’ve been looking over the -09 draft and have created a Perl client module against Pebble as well as LE’s new testing endpoint. I’m curious about whether the specification intends to define Challenge objects. They appear to exist, of course, but they’re not defined as objects per se in section 7.1 of the draft. Thank you! -Felipe Gasper Mississauga, ON
Change:
The value of "RateLimit-Reset" is generated at response time: a client aware of a significant network latency MAY behave accordingly <del> and use other information (eg. the "Date" response header field, or </del> <ins> and use other information (e.g. the "Date" response header field, or </ins> otherwise gathered metrics) to better estimate the "RateLimit-Reset" moment intended by the server.

Discussion:
Fix typos
I'm really sorry for the poor Camilleri :) Wu Ming's "Q" is really worth reading though URL(novel)
What, no Eco? :)
No warnings
There are six lines that are marked as too long.: It might make sense to break these into two lines: and add text saying "Shown on two lines for clarity" or something.
3 fixed ;)
NAME Can this be closed now?
Looks good - thanks for the literary recommendations; I already followed inspector Montalbano's deeds, but Q looks an interesting addition... if/whenever my son gives me some time to read! :smile:
Change:
its first cryptographic handshake message, which for TLS is the ClientHello.  Servers might need to parse the entire ClientHello (e.g., to access extensions such as Server Name Identification (SNI) <del> or Application Layer Protocol Negotiation (ALPN)) in order to decide </del> <ins> or Application-Layer Protocol Negotiation (ALPN)) in order to decide </ins> whether to accept the new incoming QUIC connection.  If the ClientHello spans multiple Initial packets, such servers would need to buffer the first received fragments, which could consume excessive

Discussion:
as well as other instances of the term. RFC 7301 does indeed hyphenate (and that's correct, since "application-layer" is being used as a single unit to describe "protocol").
URL says the registry is
Change:
the length, in network byte order.  If empty, any non-origin- specific token can be redeemed.  If the string contains multiple origin names, they are delimited with commas "," without any <del> whitespace. </del> <ins> whitespace.  If this field is not empty, the Origin MUST include its own name as one of the names in the list. </ins> When used in an authentication challenge, the "PrivateToken" scheme uses the following attributes:

Discussion:
Spec says: and and also The sender requirements are implicit. I'm guessing that the sender also MUST include it's own origin name in the non-empty case. Should the spec just state that?
Change:
SuppPrivInfo is omitted <del> The ACE_Salt "cnf" structure specifying HMAC-based key derivation of a symmetric key with SHA-256 as hash function and a random salt value is provided in kdf-cnf. A response that declines any operation on the requested resource is constructed according to Section 5.2 of RFC 6749 [20], (cf. Section 5.7.3. of draft-ietf-ace-oauth-authz [21]). </del> <ins> The "cnf" structure in the access token is provided in kdf-cnf. </ins> 3.3.1.

Discussion:
The normative specification of how to use a salt for deriving a symmetric key to use between C and RS is changed into an example using cnf = COSE_key.
The text claims to present an example, but contains a lot of normative language (probably heritage from when it was normative text). I don't think that goes well together and it leaves the reader with an unclear feeling as to where the example ends and normative text resumes. I would suggest to remove all normative language from the example and make it clear at which point the example ends and normative text resumes. I do like the idea to present this mechanism as an example however, since it is really up to the applications how they retrieve a key based on a key identifier, and I believe derivation is a fine example here.
In 9624eea the normative text is removed from the example and the example is moved to the end of the section to separate the example from the rest of the text.
Just to clarify if my understanding is correct: The proposal says that if the access token contains but no , the RS needs to derive K{C, RS} in some application-specific way?
Yes, with the interpretation that "derive" could mean "look up", "retrieve" etc. I.e. the RS needs to know how to obtain k{C, RS} from kid. Can the text be further clarified?
No, this is what I also think that the text says. Thus, I am fine merging this PR.
Since two co-authors are OK I merge this now. Further comments can be added on the master branch.
Change:
Compute SAN A and SAN B in the same way as the client. <del> Open a TLS connection to the domain name being validated on the requested port, presenting SAN A in the SNI field.  In the ClientHello initiating the TLS handshake, the server MUST include a server_name extension (i.e., SNI) containing SAN A.  The server SHOULD ensure that it does not reveal SAN B in any way when making the TLS connection, such that the presentation of SAN B in the returned certificate proves association with the client. </del> <ins> Open a TLS connection to TCP port 443 the domain name being validated on the requested port, presenting SAN A in the SNI field.  In the ClientHello initiating the TLS handshake, the server MUST include a server_name extension (i.e., SNI) containing SAN A.  The server SHOULD ensure that it does not reveal SAN B in any way when making the TLS connection, such that the presentation of SAN B in the returned certificate proves association with the client. </ins> Verify that the certificate contains a subjectAltName extension containing dNSName entries of SAN A and SAN B and no other

Discussion:
I spotted a typo/error introduced by this PR and submitted a follow-up: URL
Since we did not get consensus around , we should be explicit that HTTP is TCP port 80, and HTTPS is TCP port 443, and that holds for redirects as well. The is pretty much a minor wording change only.