jiebi/CodeConvo huggingface dataset:
Change:
specification as described in QUIC, QUIC-TLS, and RFC9002, with the following changes: <del> The version field of long headers is TBD.  Note: Unless this document is published as an RFC, implementations should use the provisional value 0xff020000, which might change with each edition of this document. </del> <ins> The version field of long headers is 0x709a50c4. </ins> The salt used to derive Initial keys in Section 5.2 of QUIC-TLS changes to:

Discussion:
Get one from IANA
I'll ask for 0x70 9a 50 c4 .
Feedback from NAME was that you should do that after publishing a revision with that number in it. I second that.
Change:
required to keep the server functional and its credentials up-to- date. <del> The overall idea is that it's nearly as easy to deploy with a CA- issued certificate as a self-signed certificate, and that once the operator has done so, the process is self-sustaining with minimal manual intervention.  Close integration of ACME with HTTPS servers, for example, can allow the immediate and automated deployment of certificates as they are issued, optionally sparing the human administrator from additional configuration work. </del> <ins> In this way, it would be nearly as easy to deploy with a CA-issued certificate as with a self-signed certificate.  Furthermore, the maintenance of that CA-issued certificate would require minimal manual intervention.  Such close integration of ACME with HTTPS servers would allow the immediate and automated deployment of certificates as they are issued, sparing the human administrator from much of the time-consuming work described in the previous section. </ins> 3.

Discussion:
Several comprehensibility improvements to the first three sections of the draft RFC. For clarity about the contents of this pull request, please consider using the option (git CLI) or the "rich diff" option (GitHub web interface) to evaluate it, in preference to a traditional line-based diff.
NAME - I think these changes are valuable. Thank you! I don't personally have any qualms/feedback having read through the diff but it would help get more eyes on this if you emailed the ACME mailing list with a brief mention of your PR (even though it's strictly editorial I think more folks monitor the list than the Github repo).
LGTM. Thanks NAME !
Change:
%%% Record Layer <del> The TLSPLaintext.fragment value, containing the byte encoding of a </del> <ins> The TLSPlaintext.fragment value, containing the byte encoding of a </ins> handshake or an alert message, or the raw bytes of the application's data to send.

Discussion:
I believe the markdown has not yet been sent to the RFC Editor, so we can save them the trouble by getting this in.
Change:
Link header with link relation "next" indicating a URL to retrieve further entries. <del> A URI from which a list of certificates issued for this account can be fetched via a GET request.  The result of the GET request MUST be a JSON object whose "certificates" field is an array of strings, where each string is the URI of a certificate.  The server SHOULD NOT include expired or revoked certificates.  The server MAY return an incomplete list, along with a Link header with link relation "next" indicating a URL to retrieve further entries. </del> 6.1.3. An ACME registration resource represents a client's request for a

Discussion:
The registration object already contains a list of certificate applications, and each application contains a link to the resulting certificate if one was issued. This reduces the number of primitives that an ACME server has to support.
Change:
of these protections includes padding messages in order to produce ciphertexts of standard length.  While this protection is highly recommended it is not mandatory as it can be costly in terms of <del> performance for clients and the MS. </del> <ins> performance for clients and the SP. </ins> Message content can be deniable if the signature keys are exchanged over a deniable channel prior to signing messages.

Discussion:
This PR addresses URL
Thanks!
In the context of this document, the meaning of the term Messaging Service (MS) seems a little unclear to me. The document states that the protocol is intended to be embedded in a concrete protocol such as XMPP. However, is a MS meant to be a messaging service such as SMS or MMS? Or a service on the application layer, such as FB or WhatsApp? Essentially who provides / controls the AS and DS? I would be grateful for some clarification on this. Thanks.
It is meant to mean application layer, would changing that to "service provider" work better for you?
Thank you. I do think that the term service provider is less ambiguous.
Ack, will fix soon.
I can make a PR, if you want?
Sure, please go for it.
Fixed by
Change:
Note that this relaxes the constraints on certificate-signing algorithms found in prior versions of TLS. <ins> If the certificate_extensions list in the certificate request message was non-empty, the end-entity certificate MUST match the extension OIDs recognized by the client, as described in certificate-request. </ins> Note that, as with the server certificate, there are certificates that use algorithms/algorithm combinations that cannot be currently used with TLS.

Discussion:
This PR includes CertificateRequest changes discussed at the TLS WG Interim: Removes certificate_types, which are no longer needed. Adds client cert selection by certificate extension values. This helps make CertificateRequest more specific and eliminate the need for the confusing "Choose a certificate" UI.
Change:
1.4.1. <del> The "$" refers to the of the argument, i.e., to the argument as a whole.  Every JSONPath expression begins with the root node identifier. </del> <ins> The root node identifier "$" refers to the root node of the argument, i.e., to the argument as a whole.  Every JSONPath expression begins with the root node identifier. </ins> <del> The "@" refers to the in the context of the evaluation of a filter expression (described later). </del> <ins> The current node identifier "@" refers to the current node in the context of the evaluation of a filter expression (described later). </ins> 1.4.2.

Discussion:
This is currently done inconsistently and doesn't add much value. Instead, define terms in the Terminology section. Reviewers please note: is not modified. This avoids a clash with URL which deletes the term.
Let's wait until lands before sorting this PR out. Meanwhile, rebased on main and kept one of the italicisations which was previously removed.
I've reinstated the other italics which NAME favoured.
Change:
3.2.2. <del> The Sender Sequence Number is initialized to 0.  The supported types of replay protection and replay window length is application specific and depends on how OSCORE is transported, see replay-protection.  The default is DTLS-type replay protection with a window size of 32 initiated as described in Section 4.1.2.6 of RFC6347. </del> <ins> The Sender Sequence Number is initialized to 0. The supported types of replay protection and replay window length is application specific and depends on how OSCORE is transported, see replay-protection.  The default is DTLS-type replay protection with a window size of 32 initiated as described in Section 4.1.2.6 of RFC6347. </ins> 3.3.

Discussion:
Addressing issue : Reverting to previous method of updating replay window (section B.1.2, text was previously in 7.5) Removing item 2 in section 7.5
Hi, I do not think that the new suggested Echo procedure specified in 7.5 and B.1.2 is secure with GCM. The procedure intentionally reuses a nonce. As the Plaintext and/or AAD changes, I think the nonce reuse will allow an attacker to calculate the GCM authentication key H, therefore compromising integrity for all following messages the server receives. I don't think we want a procedure that is dependant on the AEAD algorithm. Are there any ways to fix this or should we revert to the previous procedure where the server first need to make sure that it uses a fresh nonce and then send Echo? What do you think NAME ? In Section 7.5, bullet 2 The endpoints can update the server’s Replay Window by using the Echo option [I-D.ietf-core-echo-request-tag], see Appendix B.1.2 for an example. This method only updates the Replay Window and does not update the server’s Sender Sequence Number, so it MUST be complemented by a method for updating the Sender Sequence Number (e.g. by using Appendix B.1.1) if the application allows for the server to encode the AEAD nonce using its Sender Sequence Number in responses to regular requests, or if the server supports Observe. This method MUST NOT be used unless the client can guarantee that its own Sender Sequence Numbers are not reused (e.g. by using Appendix B.1.1). In Appendix B.1.2
Yes you are correct. I was only thinking of the use of CCM which does not have this problem.
I merged PR - reverting to the processing in -15.
I close this issue now, if there are still comments we can reopen it.
Change:
Because the setting has no defined meaning, the value of the setting can be any value the implementation selects. <del> Setting identifiers which were used in HTTP/2 where there is no </del> <ins> Setting identifiers which were defined in HTTP2 where there is no </ins> corresponding HTTP/3 setting have also been reserved (iana-settings). <del> These settings MUST NOT be sent, and their receipt MUST be treated as a connection error of type H3_SETTINGS_ERROR. </del> <ins> These reserved settings MUST NOT be sent, and their receipt MUST be treated as a connection error of type H3_SETTINGS_ERROR. </ins> Additional settings can be defined by extensions to HTTP/3; see extensions for more details.

Discussion:
Specifically those defined in RFC 7540.
URL says: The table of defined HTTP/3 settings is in URL The diverges a little bit from everything that is stated in RFC 7540. is stated as reserved in IANA but no mention of it in RFC 7540. Therefore it is ambiguous if an HTTP/3 implementation should reject this Type value. The range is reserved for HTTP/2 experimental use. Its not clear if I should reject those too. IANA also includes some extension settings: (RFC 8441), 0x10 (MS-HTTP2E). I might expect to be reused by some extension that defines Websocket over H3. seems like something that is not reusable? And finally, we have Extensible Priorities that defines SETTINGSDEPRECATEHTTP2_PRIORITIES and wants to claim . I don't expect any need to also define that in HTTP/3 settings, unless the purpose is to prohibit it. In summary, I don't think there is a huge problem. Maybe we can editorialize our way out of the ambiguity. However, I'd really like to avoid H/3 connections instantly failing due to implementations disagreeing about this rejection requirement.
I overlooked that NAME already made the point about in .
The intent is to reserve things that are defined in 7540; things reserved by other extensions might later be defined for HTTP/3, so there shouldn't be any assumptions. Let's make that requirement crisper to apply specifically to those values explicitly reserved.
WfM
I wonder if we should ask IANA if they can tell how it came to be that 0x0 was marked as reserved with 7540 as the reference even though we are failing to see what part of 7540 should be effectuating that.
Change:
value "nonce" using the input challenge and Issuer key identifier as follows: <del> The rsabssa_blind function is defined in BLINDRSA, Section 5.1.1.. The Client stores the nonce and challenge_digest values locally for use when finalizing the issuance protocol to produce a token (as described in public-finalize). </del> <ins> The PrepareIdentity and Blind functions are defined in Section 4.1 of BLINDRSA and Section 4.2 of BLINDRSA, respectively.  The Client stores the nonce and challenge_digest values locally for use when finalizing the issuance protocol to produce a token (as described in public-finalize). </ins> The Client then creates a TokenRequest structured as follows:

Discussion:
This link is broken in a few ways. Note that the links has an trailing period in it, which is only part of the problem there; there is no Section 5.1.2 or Section "5.1.2.". Also, the function is called "BlindSign" in that version of the draft.
In the issuance protocol draft, there are a few places where it is assumed that a value will be a certain length, but no effort has been made to explicitly set a length. In : Is the 0x0002 two octets? Sure, you might readily assume that, but nothing says that explicitly. The same assumption appears in Sections 5.1 and 5.5.
Change:
and destination addresses, source and destination UDP ports, and the Destination Connection ID field.  The flow label generation MUST be designed to minimize the chances of linkability with a previously <del> used flow label, as this would enable correlating activity on multiple paths; see migration-linkability. </del> <ins> used flow label, as a stable flow label would enable correlating activity on multiple paths; see migration-linkability. </ins> A possible implementation is to compute the flow label as a cryptographic hash function of the source and destination addresses,

Discussion:
The text was probably backwards, but rather than invert it, remove the indirect reference to the subject of the claim and be explicit.
Erik Kline said:
Change:
[TODO: define how we want to structure this registry when the time comes] <ins> 7.2. The following value [will be/has been] registered in the "IETF URN Sub- namespace for Registered Protocol Parameter Identifiers" registry, following the template in RFC3553: Initial contents: The types and descriptions in the table in errors above, with the Reference field set to point to this specification. </ins> 8. The text in message-transport is based extensively on

Discussion:
ACME has a pretty well defined error structure, including RFC 8707 problem documents. We should look at adopting that.
Fixed by
Change:
5. <ins> 5.1. One of the risks of deploying a short-lived credential system based on absolute time is client clock skew.  If a client's clock is sufficiently ahead or behind of the server's clock, then clients will reject credentials that are valid from the server's perspective. Clock skew also affects the validity of the original certificates. The lifetime of the delegated credential should be set taking clock skew into account.  Clock skew may affect a delegated credential at the beginning and end of its validity periods, which should also be taken into account. 6. </ins> This document registers the "delegated_credentials" extension in the "TLS ExtensionType Values" registry.  The "delegated_credentials" extension has been assigned a code point of 34.  The IANA registry

Discussion:
From Martin: I wonder how much more needs to be said about expiration dates and allowance for clock skew. We haven't had any trouble with the mechanism proposed here (to my knowledge), but we've had plenty of trouble with ESNI deployment. Maybe the design here is sufficiently superior that it is less susceptible to problems, but it's not clear that this is indeed the case. Our implementation follows the spec when it comes to the validity period, but we can't really prevent skew from causing credentials to be rejected. What this does is that it creates a fixed notBefore equivalent for the DC that is relative to the notAfter. This effectively means that servers need to set valid_time values that aren't too far in the future based on their tolerance for client clock skew. For a 7-day credential, you might get 5 good days of use. A little bit of a nod in this direction might go a long way to avoiding deployment problems.
Fixed in
Change:
The sequence number is incremented after reading or writing each record.  The first record transmitted under a particular set of <del> traffic keys record key MUST use sequence number 0. </del> <ins> traffic keys MUST use sequence number 0. </ins> Sequence numbers do not wrap.  If a TLS implementation would need to wrap a sequence number, it MUST either rekey (key-update) or

Discussion:
I forsee some merge conflicts in the future, as there's already and I have plans to rototill this section a bit more than you do here.
This won't conflict with . Git is good at detecting identical changes.
Change:
"prep_msg" is its next VDAF message. This output message for each report in <del> AggregateContinueReq.prepare_shares is then sent to the leader in an </del> <ins> AggregateContinueReq.prepare_steps is then sent to the leader in an </ins> AggregateContinueResp message, structured as follows: <del> The order of AggregateContinueResp.prepare_shares MUST match that of the PrepareStep values in "AggregateContinueReq.prepare_shares".  The </del> <ins> The order of AggregateContinueResp.prepare_steps MUST match that of the PrepareStep values in "AggregateContinueReq.prepare_steps".  The </ins> helper's response to the leader is an HTTP status code 200 OK whose body is the AggregateContinueResp and media type is "message/dap- aggregate-continue-resp".  The helper then awaits the next message

Discussion:
The prepare_shares fields were always of type PrepareStep. To match the convention used for most other field names, I change the name of the field to match its type. (There is no "PrepareShare" type.)
Change:
3. This document defines a new extension type <del> (compress_certificates(TBD)), which is used by the client and the server to negotiate the use of compression for their certificate chains, as well as the choice of the compression algorithm. By sending the compress_certificates extension, the client indicates to the server the certificate compression algorithms it supports. The "extension_data" field of this extension in the ClientHello SHALL contain a CertificateCompressionAlgorithms value: If the server supports any of the algorithms offered in the ClientHello, it MAY respond with an extension indicating which compression algorithm it chose.  In that case, the "extension_data" SHALL be a CertificateCompressionAlgorithm value corresponding to the chosen algorithm.  If the server has chosen to not use any compression, it MUST NOT send the compress_certificates extension. </del> <ins> (compress_certificate(TBD)), which can be used to signal the supported compression formats for the Certificate message to the peer.  Whenever it is sent by the client as a ClientHello message extension (RFC5246, Section 7.4.1.4), it indicates the support for compressed server certificates.  Whenever it is sent by the server as a CertificateRequest extension (I-D.ietf-tls-tls13, Section 4.3.2), it indicates the support for compressed client certificates.  Note that CertificateRequest messages are not supported by TLS versions prior to 1.3. By sending a compress_certificate extension, the sender indicates to the peer the certificate compression algorithms it is willing to use for decompression.  The "extension_data" field of this extension SHALL contain a CertificateCompressionAlgorithms value: There is no ServerHello extension that the server is required to echo back. </ins> 4. <del> If a compression algorithm has been negotiated, server and client MAY compress their corresponding Certificate messages and send them in the form of the CompressedCertificate message (replacing the </del> <ins> If the peer has indicated that it supports compression, server and client MAY compress their corresponding Certificate messages and send them in the form of the CompressedCertificate message (replacing the </ins> Certificate message). The CompressedCertificate message is formed as follows: <ins> The algorithm used to compress the certificate.  The algorithm MUST be one of the algorithms listed in the peer's compress_certificate message. </ins> The length of the Certificate message once it is uncompressed.  If after decompression the specified length does not match the actual length, the party receiving the invalid message MUST abort the

Discussion:
This allows for stateless parsers to easily understand the contents of the message without having to keep track of the handshake state. This also decouples client and server compression parameters, allowing compression being negotiated in only one direction.
LGTM, added just a couple of small nits.
Looks good to me.
Change:
such that its length equals the size of the largest possible Certificate (message) covered by the same ESNI key. <del> [[OPEN ISSUE: Do we want "encrypted_server_name" in EE?  It's clearer communication, but would make it so you could not operate a current TLS 1.3 server as a backend server.]] </del> 6. In general, this mechanism is designed only to be used with servers

Discussion:
As per discussion in URL this would require changes to Split Mode backend servers, and it turns out that even for plain "server_name" this behaviour is pretty much useless.
Change:
Since the only the math is changed by changing the curve, the curve is not fixed for any of the algorithm identifiers we define. <ins> Shared Secret to Byte String: Once the shared secret is computed using the correct mathematics, the resulting value needs to be converted to a byte string to run the KDF function.  The X coordinate is used for all of the curves defined in this document. For curves X25519 and X448, the resulting value is used directly as it is a byte string of a known length.  For the P-256, P-384 and P-521 curves, the X coordinate is run through the I2OSP function defined in RFC3447 using the same computation for n as is defined in ECDSA. </ins> Ephemeral-static or static-static: The key agreement process may be done using either a static or an ephemeral key for the sender's side.  When using ephemeral keys, the sender MUST generate a new

Discussion:
Response to note from Göran Selander 1) we need to say where the secret is derived from 2) how it is formatted, and 3) why we are not using KA and KB in the KDF step.
Change:
This document calls for the addition of "resolver.arpa" to the Special-Use Domain Names (SUDN) registry established by RFC6761. <del> This will allow resolvers to respond to queries directed at themselves rather than a specific domain name.  While this document uses "resolver.arpa" to return SVCB records indicating designated encrypted capability, the name is generic enough to allow future reuse for other purposes where the resolver wishes to provide information about itself to the client. The "resolver.arpa" SUDN is similar to "ipv4only.arpa" in that the querying client is not interested in an answer from the authoritative "arpa" name servers.  The intent of the SUDN is to allow clients to communicate with the Unencrypted Resolver much like "ipv4only.arpa" allows for client-to-middlebox communication.  For more context, see the rationale behind "ipv4only.arpa" in RFC8880. </del> IANA is requested to add an entry in "Transport-Independent Locally- Served DNS Zones" registry for 'resolver.arpa.' with the description

Discussion:
Thanks for the painless read! Just a few trivial comments. Minor: The editorial commentary in the IANA Considerations section seems out of place -- generally IANA Considerations is, well, requests to IANA, not interesting and fun trivia about the resources being requested. But, IANA are smart enough to disregard the superflous material. Nits: , The client can still use others records in the same response s/others/other/ , provides provides s/provides//