jiebi/CodeConvo huggingface dataset:
Change:
6.3. <del> Inputs: - "server_origin": The server origin to redeem a token for. - "target": The target endpoint to send the token to.  - "additional_data": Additional data to bind to this redemption request. </del> <ins> Inputs: - "context": The request context to use.  - "server_origin": The server origin to redeem a token for.  - "target": The target endpoint to send the token to.  - "additional_data": Additional data to bind to this redemption request. </ins> When a client wants to redeem tokens for a server, it should first fetch a key commitment from the server via the process described

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:
arch), in which the necessary protocol handshakes are conducted so that the transport system can select which set to use. <del> This document structures the candidates for racing as a tree as terminological convention.  While a a tree structure is not the only way in which racing can be implemented, it does ease the illustration of how racing works. </del> <ins> As a terminological convention, this document structures the candidates for racing as a tree.  While a tree structure is not the only way in which racing can be implemented, it does ease the illustration of how racing works. </ins> The most simple example of this process might involve identifying the single IP address to which the implementation wishes to connect,

Discussion:
replace DG by CL. Changed one oddity: /as to/ to /about/
"Connection establishment is only a local operation for a Datagram transport (e.g., UDP(-Lite))": I think the criterion is not Datagram transports but "transports without a handshake" or "connectionless protocols" as it is used later in the document.
I wrote, and I suggest we use "connectionless protocols" explicitly mentioning examples of UDP and UDP-Lite when used as a transport without a handshake.
To whoever plans to address this: I checked occurrences of the word "datagram" in the architecture and API drafts, and I found (only) one sentence that needs fixing on similar grounds, I think, in the API draft: in Section 8.1.4 "Timeout for keep alive packets". Surely the guidance regarding this matter in the UDP usage RFC is related to the fact that UDP(-Lite) is connectionless, not that it's datagram based.
Starting to fix this.
This LGTM
Change:
new challenge types, and they will need to specify which types of identifier they apply to. <del> [[ Editor's Note: In pre-RFC versions of this specification, challenges are labeled by type, and with the version of the draft in which they were introduced.  For example, if an HTTP challenge were introduced in version -03 and a breaking change made in version -05, then there would be a challenge labeled "http-03" and one labeled "http-05" - but not one labeled "http-04", since challenge in version -04 was compatible with one in version -03. ]] </del> 8.1. Several of the challenges in this document make use of a key

Discussion:
This is worth discussion on the list. Do we consider the current, numbered, names a draft-only thing? Do we want the final RFC to use non-numbered challenge names?
If we are going to do this, we need to update the following paragraph: Personally, I would prefer dropping the version number (i.e., not merging this PR), since if all goes well, future client development can be based on the RFC vs. the drafts. Clients will need to change which token they use, but that's hardly the biggest change between what's deployed today and what's in this spec.
Will update to remove the editor's note.
Could possibly use some additional language about the name + version scheme we are using but I couldn't come up with anything that really worked.
Change:
on their default ports.  Note that in this configuration, ALPN negotiation does not defend against cross-protocol downgrade attacks. <del> These keys are automatically mandatory if present.  (See Section 7 of SVCB for the definition of "automatically mandatory".) </del> 4.2. This key is used to indicate the target port for connection ((SVCB Section 6.2)).  If omitted, the client SHALL use the default port for <del> each transport protocol (853 for DNS over TLS, 443 for DNS over </del> <ins> each transport protocol (853 for DNS over TLS DOT, 443 for DNS over </ins> HTTPS). <del> This key is automatically mandatory if present. </del> <ins> This key is automatically mandatory if present.  (See Section 7 of SVCB for the definition of "automatically mandatory".) </ins> 4.3.

Discussion:
This change removes the default protocol, which is currently DNS over TLS ("dot"). Several readers have expressed concern that this default is confusing.
Blocked by URL
Section 5.1 says this: The examples are all like this: RFC 6570 says this: I assume that we don't want passed in the SVCB record. Should we clarify that MUST be in relative form, i.e., just the path portion of the URI?
As a normative matter, I think this is already settled in the text, but I'm happy to improve clarity of the description.
Yeah, I think this technically covers it (), but it would be nice to say something at the start of the paragraph to specify that this is just a path segment of the URL.
approved with 1 question
Change:
working key for the TLS handshake. As detailed in delegated-credentials, the delegated credential is <del> cryptographically bound to the end-entity certificate and the protocol in which the credential may be used.  This document specifies the use of delegated credentials in TLS 1.3 or later; their use in prior versions of the protocol is explicitly disallowed. </del> <ins> cryptographically bound to the end-entity certificate with which the credential may be used.  This document specifies the use of delegated credentials in TLS 1.3 or later; their use in prior versions of the protocol is explicitly disallowed. </ins> Delegated credentials allow the server to terminate TLS connections on behalf of the certificate owner.  If a credential is stolen, there

Discussion:
As discussed in URL and subsequent.
I have responded to the two comments. No idea why CI is busted.
looks like the CI segfaulted :) I'll manually test locally and merge
Please add yourself to acknowledgements as well. remove change in line 192 as well "Each delegated credential is bound to a specific version of TLS and signature". somehow i cant comment on changes that you haven't made. Dear TLS WG, While we were implementing delegated credentials we came up with the following two problems. I thank David Benjamin for communicating the first to me. The first is that a delegated credential is pinned to a particular version of TLS. Unfortunately this means that the rollout of a new version of TLS (which libraries consider that they can do on their own) makes an existing set of delegated credentials unusable, and the signer of delegated credentials needs to accept a new version of TLS as valid before the extension can be used with a new version. This is similar to the issues prompting draft-wood-tls-external-psk-importer-00 where PSKs depend on negotiated parameters, and thus are difficult to use in practice. The second is that the DelegatedCredential indicates the algorithm that was used to sign it. Someone who is a bit careless when implementing might take that literally with the result that they verify a DelegatedCredential with RSA algorithm and the certificate is really an ECDSA certificate. I'll submit a PR with text for security considerations/rewording the verification steps. Sincerely, Watson
Change:
The expand_left() function outputs 16 octets, with its first argument in the most significant bits, its second argument in the least <del> significant byte, and zeros in all other positions.  Thus, </del> <ins> significant byte, its third argument in the second least significant byte, and zeros in all other positions.  Thus, </ins> expand_right() is similar, except that the second argument is in the <del> most significant byte, and the first argument is in the least significant bits.  Therefore, </del> <ins> most significant byte, the third is in the second most significant byte, and the first argument is in the least significant bits. Therefore, </ins> Similarly, truncate_left() and truncate_right() take the most significant and least significant bits, respectively, from a

Discussion:
in accordance with the 2nd crypto review
In the second crypto review () there was a note that plaintexts of different lengths might end up with similar results, if the extra bits were zeros. The suggestion to fix this was to update the path index to also include the length.
Looks good, except for the missing parenthesis.
Change:
If the two Web servers are operated by different entities, the inter- server signaling mechanism needs to be agreed upon, either by standardization or by other means of agreement.  Existing protocols <del> (for example SIP RFC3261 or XMPP RFC6120) could be used between servers, while either a standards-based or proprietary protocol could be used between the browser and the web server. </del> <ins> (e.g.  SIP RFC3261 or XMPP RFC6120) could be used between servers, while either a standards-based or proprietary protocol could be used between the browser and the web server. </ins> For example, if both operators' servers implement SIP, SIP could be used for communication between servers, along with either a standardized signaling mechanism (e.g.  SIP over WebSockets) or a proprietary signaling mechanism used between the application running in the browser and the web server.  Similarly, if both operators' <del> servers implement XMPP, XMPP could be used for communication between XMPP servers, with either a standardized signaling mechanism (e.g. XMPP over WebSockets or BOSH) or a proprietary signaling mechanism used between the application running in the browser and the web server. </del> <ins> servers implement Extensible Messaging and Presence Protocol (XMPP), XMPP could be used for communication between XMPP servers, with either a standardized signaling mechanism (e.g.  XMPP over WebSockets or BOSH) or a proprietary signaling mechanism used between the application running in the browser and the web server. </ins> The choice of protocols for client-server and inter-server signalling, and definition of the translation between them, is

Discussion:
This deals with some of Meral's GEN-ART comments.
I can see putting it back, but we should be consistent there were two e.g. and two for examples. My matchy-matchy tendencies getting to me.
:-) I can flip it in the other direction. Sometimes I show off my English skills, othertimes I want to write simple English. Trapped by my own filters .... the review ended up in my gen-art inbox, which I stopped reading years ago when I left the gen-art team....
No worries. I would go with whatever the RFC editor is going to end up doing, but to be honest I don’t know which they’d prefer. spt
Change:
version in Version Negotiation packets, then the old version is no longer accepted. <del> 11. </del> <ins> 12. </ins> This document has no actions for IANA. <del> 12. </del> <ins> 13. </ins> See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for

Discussion:
addresses issue
I think the applicability draft may benefit from exploring connection migration strategies as described in: URL
Do we also need to say anything about use of 0-byte CID? See quicwg/base-drafts
The transport draft already says:
addressed by PR and one more sentence
I don’t see any text related to connection migration on that PR.
sorry wrong PR; should be and is already merged
good modulo typos
Change:
Omitting the fields and handshake messages required for preserving backwards-compatibility with earlier TLS versions. <del> More compact encodings, omitting unnecessary values. </del> <ins> More compact encodings. </ins> <del> A template-based specialization mechanism that allows for the creation of application specific versions of TLS that omit unnecessary values. </del> <ins> A template-based specialization mechanism that allows pre- populating information at both endpoints without the need for negotiation. </ins> For the common (EC)DHE handshake with pre-established certificates, cTLS achieves an overhead of 45 bytes over the minimum required by

Discussion:
This update aims to bring the template-based optimization to the center and focuses on the certificiate-based authentication exchange. Included in this version is the idea to omit the random values transmitted by the client and the server by hashes of the ephemeral public keys.
Change:
WireGuard is an IP-layer protocol designed as an alternative to IPsec WireGuard for certain use cases.  It uses UDP to encapsulate IP datagrams between peers.  Unlike most transport security protocols, <del> which rely on PKI for peer authentication, WireGuard authenticates peers using pre-shared public keys delivered out-of-band, each of which is bound to one or more IP addresses.  Moreover, as a protocol suited for VPNs, WireGuard offers no extensibility, negotiation, or cryptographic agility. </del> <ins> which rely on Public Key Infrastructure (PKI) for peer authentication, WireGuard authenticates peers using pre-shared public keys delivered out-of-band, each of which is bound to one or more IP addresses.  Moreover, as a protocol suited for VPNs, WireGuard offers no extensibility, negotiation, or cryptographic agility. </ins> 3.4.3.

Discussion:
Addresses
Comment from Ekr'r review of -10: S 3.3.5. CurveCP [CurveCP] is a UDP-based transport security protocol from Daniel J. Bernstein. Unlike other security protocols, it is based entirely upon highly efficient public key algorithms. This removes many pitfalls associated with nonce reuse and key synchronization. This text is going to be confusing to people. Not to say that CurveCP is bad, and the primitives it uses are fast, but they're not any faster than those used by TLS, QUIC, or tcpcrypt. I think the consensus here is that it's not currently practical to have a general purpose transport protocol that doesn't do key establishment and then use symmetric keys. (This is the same reason why we weren't able to use public key encryption for QUIC CID encryption). Reply from Kyle: Good point. We could discuss the tradeoff between performance and security that DJB was trying to achieve, but that is probably out-of-scope for this document, so we should stick to a value-free description (e.g., "based entirely on public key algorithms") and let it go with that.
LGTM!
Change:
443 (see also alpnpid of [RFCthis]}) <del> 8.2. </del> <ins> 6.2. </ins> This document registers two new URI schemes, namely "coap+tcp" and "coaps+tcp", for the use of CoAP over TCP and for CoAP over TLS over

Discussion:
This is an extremely rough merge of core-coap-tcp-tls and core-coap-websockets. The main intent was to get all the material into one draft with a potential outline and next perform an overall editorial pass.
With the merge of websockets-07, the scope of coap-tcp-tls is extended to include CoAP over WebSockets. The draft title should reflect that change in scope.
I probably would stay explicit (but then I'm biased -- RFC 3095 :-) CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
WFM.
Neglected to close with
Change:
operational status, health, configuration or construction that have security relevance.  Evidence is appraised by a Verifier to establish its relevance, compliance, and timeliness.  Claims need to be <del> collected in a manner that is reliable.  Evidence needs to be securely associated with the target environment so that the Verifier cannot be tricked into accepting Claims originating from a different environment (that may be more trustworthy).  Evidence also must be protected from man-in-the-middle attackers who may observe, change or misdirect Evidence as it travels from Attester to Verifier.  The timeliness of Evidence can be captured using Claims that pinpoint the time or interval when changes in operational status, health, and so forth occur. </del> <ins> collected in a manner that is reliable such that a Target Environment cannot lie to the Attesting Environment about its trustworthiness properties.  Evidence needs to be securely associated with the target environment so that the Verifier cannot be tricked into accepting Claims originating from a different environment (that may be more trustworthy).  Evidence also must be protected from man-in-the-middle attackers who may observe, change or misdirect Evidence as it travels from Attester to Verifier.  The timeliness of Evidence can be captured using Claims that pinpoint the time or interval when changes in operational status, health, and so forth occur. </ins> 8.2.

Discussion:
`
This is trying say that the Target Environment can't lie to the Attesting Environment about its trustworthiness properties.
Spot on. A text proposal (NEW) based on Ned's comment:
Change:
Even though a YANG module is not defined for this interaction, the response body MUST conform to the following YANG-modeled format: <ins> As it is possible that the receiver may return custom capability URIs, the publisher MUST ignore any capabilities that it does not recognize. </ins> 3.4. The publisher can send the following request to learn the receiver capabilities.  In this example, the "Accept" states that the receiver <del> wants to receive notifications in XML but, if not supported, to use JSON encoding. </del> <ins> wants to receive the capabilities response in XML but, if not supported, then in JSON. </ins> If the receiver is able to reply using "application/xml", and assuming it is able to receive JSON and XML encoded notifications, <del> the response might look like this: </del> <ins> and it is able to process the RFC 8639 state machine, the response might look like this: </ins> If the receiver is unable to reply using "application/xml", the response might look like this:

Discussion:
Getting the draft ready for publication. Did file a bug with libyang folks and even though it was an operator error on my part, the default in yanglint now is to enable all features when none are mentioned. The examples now validate correctly.
Change:
encryption keys frequently, clients may be encouraged to obtain and use tickets beyond common lifetime windows of, e.g., 24 hours. Despite ticket lifetime hints provided by servers, clients SHOULD <del> dispose of pooled tickets after some reasonable amount of time that </del> <ins> dispose of cached tickets after some reasonable amount of time that </ins> mimics the session ticket encryption key rotation period. <ins> Specifically, as specified in Section 4.6.1 of RFC8446, clients MUST NOT cache tickets for longer than 7 days. </ins> In some cases, a server may send NewSessionTicket messages immediately upon sending the server Finished message rather than

Discussion:
I opted to go with "new connection" instead of "full handshake" (where appropriate), since that seemed to be the more natural phrase. Please let me know what you think! cc NAME (and thanks for the review!)
Change:
used to encrypt more than one message. More precisely, the initial secret of the ratchet for the group <del> member assigned to the leaf with index i is simply the secret of that leaf. Keys, nonces and secrets of ratchets are derived using HKDF-Expand- Label.  The context in a given call consists of (a hash of) the current Group state, the index of the sender's leaf in the ratchet tree and the position in the ratchet.  In particular, the index of the sender's leaf in the ratchet tree is the same as the index of the leaf in the AS Tree used to initialize the sender's ratchet. Ratchet_position is initialized to 1 for the first HKDF-Expand-Label call of a new ratchet and incremented for each subsequent call in that ratchet. HashRatCont[i, j] denotes a RatchetContext variable where: gshash = Hash(GropuState_[n]) leaf_index = i ratchet_position = j </del> <ins> member assigned to the leaf with node index N is simply the secret of that leaf. </ins> <del> Using this notation the ratchet for the group member at leaf i is defined to be: </del> <ins> Keys, nonces and secrets of ratchets are derived using Derive-App- Secret.  The context in a given call consists of the index of the sender's leaf in the ratchet tree and the current position in the ratchet.  In particular, the index of the sender's leaf in the ratchet tree is the same as the index of the leaf in the AS Tree used to initialize the sender's ratchet. </ins> <del> Here, AEAD.nonceLen and AEAD.keyLength denote the lengths in bytes of the nonce and key for the AEAD scheme defined by the ciphersuite. </del> <ins> Here, AEAD.nonce_length and AEAD.key_length denote the lengths in bytes of the nonce and key for the AEAD scheme defined by the ciphersuite. </ins> 11.3.

Discussion:
This PR implements a collection of comments on . It aims to achieve the goal stated by NAME of having every derivation have a different relationship, but with a simpler construction.
Ok, I think this is good enough : )
Change:
be dropped if the receiver is overloaded.  While the reliable transmission service of QUIC provides a stream-based interface to send and receive data in order over multiple QUIC streams, the <del> datagram service has a unordered message-based interface.  If needed, an application layer framing can be used on top to allow separate flows of unreliable datagrams to be multiplexed on one QUIC </del> <ins> datagram service has an unordered message-based interface.  If needed, an application layer framing can be used on top to allow separate flows of unreliable datagrams to be multiplexed on one QUIC </ins> connection. 16.

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:
ServerHello, rather than waiting for the client's "end_of_early_data" alert. <del> 4.2.8.2. </del> <ins> 4.2.8.3. </ins> As noted in zero-rtt-data, TLS provides a limited mechanism for replay protection for data sent by the client in the first flight.

Discussion:
This is how NSS behaves as well. This seems like a reasonable argument.
added the changes previously discussed.
I did not verify that the moved text is only move and no edits, but the other chunks seem okay.
NAME are you OK with this SHOULD?
Sounds reasonable. Mostly I just don't want to encourage servers to enforce anything about this.