jiebi/CodeConvo huggingface dataset:
Change:
the URL for the registration matching the old key Check that the "oldKey" field of the key-change object contains <del> the thumbprint of the key used to sign the inner JWS </del> <ins> the current account key. </ins> Check that the "newKey" field of the key-change object contains <del> the thumbprint of the key used to sign the outer JWS </del> <ins> the key used to sign the inner JWS. </ins> If all of these checks pass, then the server updates the corresponding registration by replacing the old account key with the

Discussion:
Signing with the current account key allows servers to use the same message transport authentication that they use for other requests, simplifying the verification. Also fix two spots where we still described newKey/oldKey as thumbprints.
LGTM. I had only done that signing order to be forward-compatible with some imagined future recovery scheme, but if we decide to do that someday, that patch can differ in signature order as well as whatever else.
Change:
keys as COSE_Keys of type EC2 or OKP according to Sections 7.1 and 7.2 of RFC9053, but only including the 'x' parameter in G_X and G_Y. For Elliptic Curve Keys of type EC2, compact representation MAY be <del> used also in the COSE_Key.  If the COSE implementation requires a 'y' parameter, the value y = false SHALL be used.  COSE always use compact output for Elliptic Curve Keys of type EC2. </del> <ins> used also in the COSE_Key.  COSE always uses compact output for Elliptic Curve Keys of type EC2.  If the COSE implementation requires a 'y' parameter, the value y = false or a calculated y-coordinate can be used, see comrep. </ins> 3.8.

Discussion:
First take on explaining how to calculate a Y value for old APIs not supporting the full {{SECG}} format.
Given e.g. the Julia programming language the calculations aretrivial For more constrained platforms maybe we should have some link to a paper explaining how to do this type of calculations on constrained platforms. URL URL file:///Users/emanjon/Downloads/applsci-10-URL
If a y-coordinate is required then the value ~yp SHALL be set to zero This leads to unnecesary extra code if a y value is calculated. I suggest that we reformulate this
Erik Thormarker wrote me that RFC 6090 Appendix C is a good high level reference for this.
LGTM
NAME and others: is the new text sufficient to support implementers which has to use a library requiring the y-coordinate?
Merged PR to master that addresses this
Here some comments after going through the PR.
Change:
find the correct one.  The internal structure of 'kid' values is not defined and cannot be relied on by applications.  Key identifier values are hints about which key to use.  This is not a <del> security critical field.  For this reason, it SHOULD be placed in the unprotected headers bucket. </del> <ins> security critical field.  For this reason, it can be placed in the unprotected headers bucket. </ins> This parameter holds the Initialization Vector (IV) value.  For some symmetric encryption algorithms this may be referred to as a nonce.  As the IV is authenticated by the encryption process, it <del> SHOULD be placed in the unprotected header bucket. </del> <ins> can be placed in the unprotected header bucket. </ins> This parameter holds a part of the IV value.  When using the COSE_Encrypt0 structure, a portion of the IV can be part of the

Discussion:
Some more edits in response to the review. Does not include one item that was proposed for clarification
Change:
10.2. The ACK_MP frame (types TBD-00 and TBD-01; experiments use <del> 0xbaba00..0xbaba01 or 0x42..x43) is an extension of the ACK frame defined by QUIC-TRANSPORT.  It is used to acknowledge packets that were sent on different paths when using multiple packet number spaces.  If the frame type is TBD-01, ACK_MP frames also contain the sum of QUIC packets with associated ECN marks received on the connection up to this point. </del> <ins> 0xbaba00..0xbaba01) is an extension of the ACK frame defined by QUIC- TRANSPORT.  It is used to acknowledge packets that were sent on different paths when using multiple packet number spaces.  If the frame type is TBD-01, ACK_MP frames also contain the sum of QUIC packets with associated ECN marks received on the connection up to this point. </ins> ACK_MP frame is formatted as shown in fig-mp-ack-format.

Discussion:
Given the deadline, let's first have one set of values instead of two. We may want to decide a third value set later.
Ok for me!
The current text on the defintion of ACK MP says: The figure is too wide, and I am fixing that with issue , but really we should pick just one set of identifiers, not 2. I understand that draft-liu and draft-deconinck were using these two values, but we should pick one of them, or a third one.
I submitted PR to fix this issue.
PR merged.
Fixed conflict.NAME please review and merge if you agree!
Change:
secrets: After applying the UpdatePath, the tree will have the following <del> structure, where "lp" and "np[i]" represent the leaf_priv and node_priv values generated as described above: </del> <ins> structure: </ins> 8.5.

Discussion:
URL Reviewer: Rich Salz Review result: Ready with Nits I reviewed this draft for ART. I did not review the cryptography as I am unqualified, compared with the draft authors (and other participants). Overall: I think references should be uppercase, as "[art]" should be "[ART]" Abstract: Nicely describes the problem. Is 'forward secrecy and post-compromise security' redundant? If not, there should be definitions in the draft for both terms and perhaps a forward link toe the terminology section. Introduction. "pairwise broadcast of individual messages" seems to go to far for terseness to make the sentence grammatical. The section on common strategy should have a reference or two to implementations. And do you mean "unilaterally broadcast Asymmetric keys" Or is the common technique to allow everyone to impersonate anyone? Sec 2, Terminology. Alphabetical order please. Maybe mention that MSLPlaintext, MLSCiphertext are message formats described in section 4.1; I wondered why they didn't appear in the terminology. And when I searched forward to find where they are defined, I noticed that elsewhere they are rendered as for example, and here the underscores aren't present. Consistency is a virtue. The last paragraph starts by saying "keys and secrets are used interchangeably" which is contradicted by the last sentence. Sec 2.1.2 I was consistently confused by the term "variable-size vector headers" Suggest replacing "Headers" with "Sizes" The parenthetical should not be parenthesized, the difference is important and not an aside. The example vector should be "StructWithVector" not plural, right? The examples are useful, but should be more clear that they are sample encodings of the length bytes and mark the length of the following vector in bytes. Sec 3. Short and understandable. Sec 4. Not short :) but understandable. Sec 4.2 is very useful and have a nice use of the railroad diagrams. The section title should be plural tho. "Executions" Is there any guidance to be offered on access control policies? How does A know whether or not Z can remove B? Are messages NAK'd or ignored or something else? I guess a forward link to 6.3 makes sense.

Sec 5 The worked examples are very useful. I like figure 9 Sec 6.2, nit no underscores around first use of I skimmed sec 7 and 8. The end of 8.4 'where lp and np[i] represent" confused me as I don't see those notations in the diagram that follows. Doing a spot-check of these sections it seems that overall the text is clear. Sorry, I ran out of time do finish the document. Holy cow, this is a large document with a great deal of technical detail. I'll be surprised if you got much early feedback. More time, next time, please. Table 5 says "LVL the security level" Should mention "strengh in bits" maybe.
Change:
different transport or TLS configurations but SHOULD avoid creating multiple connections with the same configuration. <del> Prior to making requests for an origin whose scheme is not "https," the client MUST ensure the server is willing to serve that scheme. If the client intends to make requests for an origin whose scheme is "http", this means that it MUST obtain a valid "http-opportunistic" response for the origin as described in RFC8164 prior to making any such requests.  Other schemes might define other mechanisms. </del> Servers are encouraged to maintain open connections for as long as possible but are permitted to terminate idle connections if necessary.  When either endpoint chooses to close the HTTP/3 session,

Discussion:
Clients MAY establish QUIC connections using the host and port indicated in the URL for "https" URLs only Non-"https" origins are able to be delegated using Alt-Svc Cribs a lot of text from .
Are we waiting on a consensus call for this?
The call has been issued and is running until Saturday UTC. If you have comments, please make them now!
Excellent! Can't wait for this to land. (Looks like I need to finish reading my WG email :>)
NAME I'll get your comments as a separate PR.
S 2.4. This text seems quite a bit more restrictive than S 9.1.1. of RFC 7540, which just allows reuse as long as the SAN is present in the cert. Is that intentional?
I think that the intent was to present equivalent text. Though the thinking about coalescing has evolved some in the meantime. We should discuss where we think the state of this discussion is at and see if we can capture something sensible.
Yes, it'd be good to capture something more up-to-date if we can come to consensus on that. Is explicit signal meant to indicate DNS and/or ORIGIN frame? If so, maybe call those two out as examples?
NAME I think the dilemma is that some of those things don't exist yet for H3. For example, Mike did some earlier work to redefine ALTSVC frame for H3 but there is yet to be equivalent for ORIGIN or secondary certs.
Yes, it's intentional. RFC7540 allows coalescing based on the cert and DNS, because you're connected to the authoritative origin. However, HTTP/3 is never connected on the authoritative endpoint for an http(s?):// URL, so you need something else to tell you that's okay. This could be an Alt-Svc record for that origin delegating to the same UDP port. This could be an ORIGIN-for-H3 frame telling you to throw caution to the wind and trust the cert, if the client thinks that's sensible.
Discussed in London; also blocked on URL defining how a client decides which connection / server to ask for a given resource.
Discussed in ZRH. Waiting for HTTP changes to materialize.
Change:
provisional answers. In RFC3264, the constraint at the signaling level is that only one <del> offer can be outstanding for a given session, but at the media stack level, a new offer can be generated at any point.  For example, when using SIP for signaling, if one offer is sent and is then canceled using a SIP CANCEL, another offer can be generated even though no answer was received for the first offer.  To support this, the JSEP media layer can provide an offer via the createOffer method whenever the JavaScript application needs one for the signaling.  The answerer can send back zero or more provisional answers and then finally end the offer/answer exchange by sending a final answer.  The state machine for this is as follows: </del> <ins> offer can be outstanding for a given session, but at the JSEP level, a new offer can be generated at any point.  For example, when using SIP for signaling, if one offer is sent and is then canceled using a SIP CANCEL, another offer can be generated even though no answer was received for the first offer.  To support this, the JSEP media layer can provide an offer via the createOffer method whenever the JavaScript application needs one for the signaling.  The answerer can send back zero or more provisional answers and then finally end the offer/answer exchange by sending a final answer.  The state machine for this is as follows: </ins> Aside from these state transitions, there is no other difference between the handling of provisional ("pranswer") and final ("answer")

Discussion:
This includes Removing my postal address. Mozilla closed that office. small editorial changes Removing bogus whitespace.
NAME PTAL
NAME I think I've got your changes and we are ready to land?
LGTM
Change:
or RSA_fixed_ECDH client authentication mechanism.) Contains the client's ephemeral ECDH public key as a byte string ECPoint.point, which may represent an elliptic curve point in <del> uncompressed or compressed format.  Curves Ed25519 and Ed448 MUST NOT be used.  Here, the format MUST conform to what the server has requested through a Supported Point Formats Extension if this extension was used, and MUST be uncompressed if this extension was not used. </del> <ins> uncompressed or compressed format.  Curves eddsa_ed25519 and eddsa_ed448 MUST NOT be used here.  Here, the format MUST conform to what the server has requested through a Supported Point Formats Extension if this extension was used, and MUST be uncompressed if this extension was not used. </ins> Actions of the sender:

Discussion:
Replace uses of Curve25519 with X25519 (and similarly with 448-bit one). Also add zero checks as required by CFRG-CURVES. Because of problems with TLS 1.2 key exchange, omitting these checks leads to security issues.
Renamed the curves to be consistent with what got merged into TLS 1.3 spec
Change:
supported by the client (cf. server_cert and ske). NOTE: A server participating in an ECDHE-ECDSA key exchange may use <del> different curves for (i) the ECDSA key in its certificate, and (ii) the ephemeral ECDH key in the ServerKeyExchange message.  The server must consider the extensions in both cases. </del> <ins> different curves for the ECDSA key in its certificate, and for the ephemeral ECDH key in the ServerKeyExchange message.  The server MUST consider the extensions in both cases. </ins> If a server does not understand the Supported Elliptic Curves Extension, does not understand the Supported Point Formats Extension,

Discussion:
Added new curves and new authors. Partial merge of draft-ietf-tls-curve25519
Change:
7. <del> Security considerations for Privacy Pass are discussed in draft- davidson-pp-architecture. </del> <ins> Security considerations for Privacy Pass are discussed in draft-ietf- privacypass-architecture. </ins> 8. <del> 8.1. </del> <ins> General privacy considerations for Privacy Pass are discussed in draft-ietf-privacypass-architecture. In order to implement this API with redemption contexts, a client needs to maintain strong privacy boundaries between different redemption contexts to avoid privacy leakage from redemptions across them.  Notably in the web/HTTP world, cross-site tracking and fingerprinting will need to be considered and mitigated in order to maintain these privacy boundaries. 9. 9.1. </ins> This specification registers a new well-known URI.

Discussion:
Initial work for fixing .
NAME
As discussed during IETF 110, the architecture document should provide guidance on how redemption contexts can be used and how they impact privacy. This is a bit of the calculus we don't yet have. cc NAME NAME
Yeah, this likely needs to be embedded both into the Architecture draft for the generic concept of a context, and then an actual instantiation of redemption contexts in the HTTP API doc.
Yep should we split out the HTTP work into a separate issue?
Thanks NAME This looks good, I have mostly just a few nits to resolve.
Change:
normal QUIC signal to the client that there is an unauthorized man in the middle. <del> 5.2.2. </del> <ins> 5.2.3. </ins> A server behind a non-shared-state retry service MUST NOT send Retry <del> packets. </del> <ins> packets for a QUIC version the retry service understands.  It MAY send Retry for QUIC versions the Retry Service does not understand. </ins> Tokens sent in NEW_TOKEN frames MUST have the first bit be set to '1'.

Discussion:
Fixes URL
Some load balancers today switch based on the SNI. Obviously, this is not version-invariant. We should add some language about this. What should such an LB when it encounters an unknown version? It probably has no choice but to forward it based on CID and hope for the best.
If the differing domains trust each other, the servers could helpfully generate Retry packets to redirect the client to the right place. This assumes a bunch of shared state, and that those servers support the same version while the LB does not. Of course, if version support differs, the VN process has serious problems.
Maybe encrypt sni will be the real standard later(see URL), I just think that there is no need for quic lb considering sni
Change:
However, absence of a component ID 2 as such does not imply use of RTCP/RTP multiplexing, as it could also mean that RTCP is not used. <del> For other than RTP-based streams, use of multiple components is </del> <ins> For other than RTP/RTCP streams, use of multiple components is </ins> discouraged since using them increases the complexity of ICE processing.  If multiple components are needed, the component IDs SHOULD start with 1 and increase by 1 for each component.

Discussion:
Fix spelling: Replace “fulfil” with “fulfill” Fix grammar: “agent sets the state…is set to Completed“ with “agent sets the state…to Completed” Make consistent with recent changes: Replace “candidate is equal to the transport address” with “candidate has the transport address” Replace “multimedia session” with “data session” Replace “media data stream” with “RTP/RTCP data stream” or just “data stream” Replace “media data” with “data”
Change:
qualified domain name (type: "dns").  If a domain name contains non- ASCII Unicode characters it MUST be encoded using the rules defined in RFC3492.  Servers MUST verify any identifier values that begin <del> with the ASCII Compatible Encoding prefix "xn-" as defined in RFC5890 are properly encoded.  Wildcard domain names (with "*" as the first label) MUST NOT be included in authorization objects. </del> <ins> with the ASCII Compatible Encoding prefix "xn--" as defined in RFC5890 are properly encoded.  Wildcard domain names (with "*" as the first label) MUST NOT be included in authorization objects. </ins> identifier-validation-challenges describes a set of challenges for domain name validation.

Discussion:
Prior to this commit the IDN prefix referenced from RFC5890 was being turned from to . This commit escapes the two dashes so they remain in the generated doc. Thanks to NAME for reporting! Resolves URL
In https://ietf-wg-URL This should be:
Opened URL with a fix. Thanks!
Change:
a client is optionally authenticated, <del> every connection produces distinct and unrelated keys, </del> <ins> every connection produces distinct and unrelated keys, and </ins> keying material is usable for packet protection for both 0-RTT <del> and 1-RTT packets, and 1-RTT keys have forward secrecy </del> <ins> and 1-RTT packets </ins> authenticated values for transport parameters of both endpoints, and confidentiality protection for server transport parameters

Discussion:
This claim isn't necessary, as the statement about suitability is what matters here.
S 7. Claims 1-RTT keys have forward secrecy This is only true if you only resume with PSK-(EC)DHE, but I don't see a requirement for this. So we need to either require this or change the text.
This obsession with forward secrecy is a hang-up from Google QUIC. I think that we should instead say that 1-RTT keys are derived from the completed cryptographic handshake instead.
Change:
response "response", servers generate an Encapsulated Response "enc_response" as follows: <del> Export a secret "secret" from "context", using the string "ohttp response" as context.  The length of this secret is "max(Nn, Nk)", where "Nn" and "Nk" are the length of AEAD key and nonce associated with "context". </del> <ins> Export a secret "secret" from "context", using the string "message/bhttp response" as context.  The length of this secret is "max(Nn, Nk)", where "Nn" and "Nk" are the length of AEAD key and nonce associated with "context". </ins> Generate a random value of length "max(Nn, Nk)" bytes, called "response_nonce".

Discussion:
Test vectors generated from the .
With , we're enforcing a 1:1 mapping between message/ohttp-req and message/bhttp, but we don't have any cryptographic enforcement of this pairing. If someone were to reuse the encapsulation mechanism in this document with another message type, say, to encapsulate application/dns-message values with a application/oblivious-dns-message wrapper, then we'd probably want to ensure that targets can't get confused between these two types. We could use the HPKE info string to separate these two protocols. (This is related to .)
The encapsulated payload could be something other than HTTP. We should be clear about our decision to do that and how alternative payloads might be carried if people wanted to do that.
The clear example here would be allowing just a DNS message body. As long as the client and target agreed, they could use that without the proxy knowing. We could just loosen the restrictions on what the body is, or we could use different content types (if you want the proxy to know what it is?).
I think that the way you would do that is to define a new media type for DNS and then just go for it. (Of course, you need to debate whether to include a length field and a transaction ID field.) Maybe we don't need to do that in this draft, but we could explain how that might look.
I'd do the following here (in line with ): Replace as the HPKE info string with the content-type of the inner message, be it or . That way, both client and target must agree on the type of encapsulated payload to actually use it. Thoughts?
That might work. We have "ohttp response" as the label for HKDF expansion on the response. What would you include there? Maybe you should just extend with "message/bhttp request" and "message/bhttp response" and then the swapping in the media type becomes trivial.
Yeah, that's what I had in mind.
Sorry about that. Misremembered how this worked; I should have double-checked.
Change:
maximum packet size to allow for unknown tunnel overheads or IP header options/extensions. <del> 14.1.1. </del> <ins> 14.2.1. </ins> Path Maximum Transmission Unit Discovery (PMTUD; RFC1191, RFC8201) relies on reception of ICMP messages (e.g., IPv6 Packet Too Big

Discussion:
This was mixed in with other packet size text. A clean split is possible. (Note that this might rot with all the other changes that are in flight. This is a straight move, so it can be rebased easy on that basis.)
Change:
Note that this document distinguishes between a WebTransport server and an HTTP/2 server.  An HTTP/2 server is the server that terminates HTTP/2 connections; a WebTransport server is an application that <del> accepts WebTransport sessions, which can be accessed via an HTTP/2 server. </del> <ins> accepts WebTransport sessions, which can be accessed using HTTP/2 and this protocol. </ins> 2.

Discussion:
There is a long and proud legacy of drafts that carry introductions concentrating on the motivations for the last design change rather than the true reasons for the protocol. This is my attempt to bring things back on the level. I didn't stop there though. I think that we should make this about HTTP/2 because we don't currently have an extended CONNECT defined for HTTP/1.1. This walks back some of the "generic HTTP" language. More changes might be needed later in the document for that to be complete, but I wanted to keep this fix localized. I did cut stuff that I think the document should still contain. I just don't think that these need to be in the introduction. That is: you can multiplex multiple sessions other protocols might take stuff from this session and transmit them in different, better ways