jiebi/CodeConvo huggingface dataset:
Change:
may now use this in the same way as if he had gotten it from a new- registration transaction. <del> 6.6. </del> <ins> 6.3.3. If a client no longer wishes to have an account key registered with the server, it may request that the server delete its account by sending a POST request to the account URI containing the "delete" field. delete (required, boolean): The boolean value "true". The request object MUST contain the "resource" field as required above(with the value "reg").  It MUST NOT contain any fields besides "resource" and "delete". Note that although this object is very simple, the risk of replay or fraudulent generation via signing oracles is mitigated by the need for an anti-replay token in the protected header of the JWS. On receiving a POST to an account URI containing a "delete" field, the server MUST verify that no other fields were sent in the object (other than "resource"), and it MUST verify that the value of the "delete" field is "true" (as a boolean, not a string).  If either of these checks fails, then the server MUST reject the request with status code 400 (Bad Request). If the server accepts the deletion request, then it MUST delete the account and all related objects and send a response with a 200 (OK) status code and an empty body.  The server SHOULD delete any authorization objects related to the deleted account, since they can no longer be used.  The server SHOULD NOT delete certificate objects related to the account, since certificates issued under the account continue to be valid until they expire or are revoked. 6.4. </ins> The identifier authorization process establishes the authorization of an account to manage certificates for a given identifier.  This

Discussion:
Adds a little more granularity to section headings.
It should be possible for a client to delete his account / registration, and to renounce authorization for a domain. The right way to do this is probably to define a "delete" object that can be POSTed to the reg/account URI, rather than having a separate endpoint (as for certificate revocation).
Change:
BERT block instead. In descriptive usage, a BERT Option is interpreted in the same way as <del> the equivalent Option with SZX == 6, except that the payload is </del> <ins> the equivalent Option with SZX == 6, except that the payload is also </ins> allowed to contain a multiple of 1024 bytes (non-final BERT block) or more than 1024 bytes (final BERT block).

Discussion:
URL - WGLC review by Esko Dijk • Page 22: "contain a multiple of 1024 bytes (non-final BERT block) or more than 1024 bytes (final BERT block)" -> Why can't the final block be 1024 bytes? I assume a final BERT block of 1024 bytes is allowed; it would be strange to switch back to SZX=6 for that purpose. What about below text -> "contain a multiple of 1024 bytes (non-final BERT block) or more than 1023 bytes (final BERT block)"
NAME - would you review and validate?
The text explains what is allowed with SZX=7 that is not allowed with SZX=6. As correctly noted, 1024 final is already allowed for SZX=6 (as is 1023, 1022, ...), so this is not explicitly listed in the list of additionally allowed cases. Maybe make clearer that this extends what has been allowed before instead of just saying that this is now allowed: s/is allowed/is also allowed/ or s//is additionally allowed/.
That seems like a simpler (if more subtle) edit.
Change:
covered by the cookie exchange during the handshake.  DTLS implementations MUST NOT update the address they send to in response to packets from a different address unless they first perform some <del> reachability test; no such test is defined in this specification. Even with such a test, an active on-path adversary can also black- hole traffic or create a reflection attack against third parties because a DTLS peer has no means to distinguish a genuine address update event (for example, due to a NAT rebinding) from one that is malicious.  This attack is of concern when there is a large asymmetry of request/response message sizes. </del> <ins> reachability test; no such test is defined in this specification and a future specification would need to specify a complete procedure for how and when to update addresses.  Even with such a test, an active on-path adversary can also black-hole traffic or create a reflection attack against third parties because a DTLS peer has no means to distinguish a genuine address update event (for example, due to a NAT rebinding) from one that is malicious.  This attack is of concern when there is a large asymmetry of request/response message sizes. </ins> With the exception of order protection and non-replayability, the security guarantees for DTLS 1.3 are the same as TLS 1.3.  While TLS

Discussion:
The DTLS 1.2 Connection ID draft (soon-to-be-RFC9146) section on "peer address update" and the text in DTLS 1.3 seems quite different. URL The "unless they first perform some reachability test" seems preferable to the soft text in soon-to-be-RFC9146, but DTLS 1.3 seems to be missing the DTLS 1.2 requirement on "The received datagram is "newer"". Feels spontanously like DTLS 1.2 and 1.3 should have similar requirements/guidance on "peer address update". FYI, I started writing some analysis of Peer Address Update in a draft that I intend to submit to T2TRG URL
Would be good to warn implementations that clients must not update the permanent server address based on the “Peer Address Update” mechanism. Using IP addresses instead of DNS names is not uncommon in e.g., IoT, DNS over DTLS (RFC 8094), and 3GPP DTLS interfaces. An client updating the permanent server address based on an MITM attack could be unable to recover.Would be good with a sentence or two on the problems changing the IP address of a gateway multiplexing a lot of DTLS connections with Connection ID. All the client and servers would have to send at least one record before the old IP address can be deactivated. Might take some time in a IoT deployment.
I tend to think we should at most provide warnings about how it's dangerous. NAME would you be willing to provide a quick PR?
In the interest of being done I opted for basically punting it to a future spec.
URL
Change:
The DNS is a common point of vulnerability for all of these challenges.  An entity that can provision false DNS records for a domain can attack the DNS challenge directly and can provision false <del> A/AAAA records to direct the ACME server to send its TLS SNI or HTTP validation query to a remote server of the attacker's choosing. There are a few different mitigations that ACME servers can apply: </del> <ins> A/AAAA records to direct the ACME server to send its HTTP validation query to a remote server of the attacker's choosing.  There are a few different mitigations that ACME servers can apply: </ins> Always querying the DNS using a DNSSEC-validating resolver (enhancing security for zones that are DNSSEC-enabled)

Discussion:
Recent developments[[0]] [[1]] [[2]] have identified real-world server/hosting configurations that violate the assumptions of TLS-SNI-01 and its currently specified replacement, TLS-SNI-02. In light of these issues and the feasibility of addressing them across the entire Internet it seems prudent that the ACME specification remove the affected challenge type pending the development of a better alternative (TLS-SNI-03?). This will allow the draft last-call to proceed while the details of TLS-SNI-03 are worked out. The "Default Virtual Hosts" sub-section of the "Operational Considerations" section is removed since it spoke exclusively to a concern with TLS-SNI-02 validation. When the dust has settled on TLS-SNI-03 we should certainly include a section that describes why TLS-SNI-01/02 were removed that could replace this information. [0]: URL [1]: URL [2]: URL
NAME I don't think we need a place-holder in-doc for this
r+ with the one comment addressedShould there be any mention of that makes sure we use in a future RFC in case if gets re-added?
Change:
taken as an endorsement of the cipher suite, extension, supported group, etc. <del> 19. </del> <ins> 14. </ins> This document is entirely about changes to TLS-related IANA registries. <del> 20.  References 20.1.  URIs [1] mailto:tls-reg-review@ietf.org [2] mailto:iesg@ietf.org </del>

Discussion:
Updated introduction and recommended column section. Deleted some irrelevant sections.
Changed from obsolete to update.
Obsoleting RFC 8447 means duplicating a lot of text and making changes to it which makes the document have awkward wording and makes the changes difficult to follow. I think it would be clearer if it were an update and just listed the changes. see Extension Types PR
At IETF 115, there was general agreement that this document could be an update as opposed to an obsolete to make it easier on IANA.
These are nits.
Change:
document returned with the error MUST include an "algorithms" field with an array of supported "alg" values. <del> 6.3. The JSON Web Signature (JWS) specification RFC7515 contains multiple JWS serialization formats.  When sending an ACME request with a non- empty body, an ACME client implementation MUST use the HTTP Content- Type RFC7231 header to indicate which JWS serialization format is used for encapsulating the ACME request payload.  The following Content-Type values may be used for this purpose: "application/jose": The JWS Compact Serialization RFC7515 MUST be used. The JWS Payload MUST NOT be detached. The JWS Unencoded Payload Option RFC7797 MUST NOT be used. "application/jose+json": Either the JWS Flattened JSON Serialization RFC7515 or the JWS General JSON Serialization RFC7515 MUST be used. The JWS Payload MUST NOT be detached. </del> <ins> Because client requests in ACME carry JWS objects in the Flattened JSON Serialization, they must have the "Content-Type" header field set to "application/jose+json".  If a request does not meet this requirement, then the server MUST return a response with status code 415 (Unsupported Media Type). </ins> <del> The JWS Unencoded Payload Option RFC7797 MUST NOT be used. The JWS Unprotected Header RFC7515 SHOULD NOT be used. In the examples below, JWS objects are shown in the Flattened JSON serialization, with the protected header and payload expressed as base64url(content) instead of the actual base64-encoded value, so that the content is readable. 6.4. </del> <ins> 6.3. </ins> It is common in deployment for the entity terminating TLS for HTTPS to be different from the entity operating the logical HTTPS server,

Discussion:
This is my attempt to find a quick way out of this content-type mess. Replaces and
This also looks good to me, thanks for drafting it!
+1 - This looks like a low complexity path forward that resolves ambiguity.
Change:
In order to help clients configure themselves with the right URLs for each ACME operation, ACME servers provide a directory object.  This should be the only URL needed to configure clients.  It is a JSON <del> object, whose keys are drawn from the following table and whose values are the corresponding URLs. </del> <ins> object, whose fields names are drawn from the following table and whose values are the corresponding URLs. </ins> There is no constraint on the actual URL of the directory except that it should be different from the other ACME server resources' URLs,

Discussion:
In the JSON , could be called a "field name" or a "key." We use both in this document, but we should consolidate one one. I think "field name" is better (and NAME agrees). In part this avoids any ambiguity with cryptographic keys.
Change:
receiver does not notify the sender of the window size.) The "right" edge of the window represents the highest validated <del> sequence number value received on the association.  Records that contain sequence numbers lower than the "left" edge of the window are </del> <ins> sequence number value received in the epoch.  Records that contain sequence numbers lower than the "left" edge of the window are </ins> rejected.  Records falling within the window are checked against a list of received records within the window.  An efficient means for performing this check, based on the use of a bit mask, is described

Discussion:
It gets reset each time the epoch does. Don't talk about values as being scoped only per association.
Change:
The "nonce" and "extensions" fields have the same value as those in the report uploaded by the client.  Similarly, the "helper_share" <del> field is the "EncryptedInputShare" from the "Report" whose index in </del> <ins> field is the "HpkeCiphertext" from the "Report" whose index in </ins> "Report.encrypted_input_shares" is equal to the index of "[aggregator]" in the task's aggregator endpoints.  [OPEN ISSUE: We usually only need to send this in the first aggregate request.  Shall

Discussion:
When constructing HPKE contexts, we now include both sender and recipient roles, and the application label also includes the PPM version. I used here because we recently submitted draft-01 of and so the next submitted draft, which would include this change, will be . I also backported the definition of struct HpkeCiphertext from the interop PR because it makes everything tidier and should be non-controversial we can get a head-start on bringing those changes into main.
Fixed, thank you! I also rewrote the relevant paragraph to acknowledge that there's two encrypted input shares and that the leader should examine the HPKE config ID of the one intended for itself. Further, I recall NAME pointing out to me that should this draft get adopted by the WG, we'll reset to something like , so is the more appropriate application label.
There's one more instance of that needs to be changed to . Otherwise, LGTM.
Change:
for equality and changes behavior based on the result can be used as an oracle to learn the client's SNI. <del> 10.8.3. </del> <ins> 10.7.3. </ins> This attack uses resumption PSKs as an oracle for dictionary attacks against a given ClientHello's true SNI.  To begin, the attacker first

Discussion:
The misrouting content no longer applies since the backend server sees the full CH, with the true SNI.
Change:
only provide a limited amount of protection for the length of that content. <del> Padding schemes only provide limited protection against an </del> <ins> Note: Padding schemes only provide limited protection against an </ins> attacker with these capabilities, potentially only forcing an increased number of guesses to learn the length associated with a given guess.  Padding schemes also work directly against

Discussion:
Addresses most of the open RFC Editor questions.
Need to update Buck's contact information to .
Fixed in .
This is a change in the RFC Editor diff that I don't think works; pulling out for separate discussion. Original: Proposed but incorrect: The intended reading is: For... HTTP/3 servers (always, regardless of 0-RTT) and HTTP/3 clients when 0-RTT is not attempted or is rejected URL maximum table capacity is 0.
Fixed in .
Should the following text be formatted using ? See the definition at . Original: Note: Padding schemes only provide limited protection against an attacker with these capabilities, potentially only forcing an increased number of guesses to learn the length associated with a given guess. Padding schemes also work directly against compression by increasing the number of bits that are transmitted. Original: Note: Simply removing entries corresponding to the field from the dynamic table can be ineffectual if the attacker has a reliable way of causing values to be reinstalled. For example, a request to load an image in a web browser typically includes the Cookie header field (a potentially highly valued target for this sort of attack), and websites can easily force an image to be loaded, thereby refreshing the entry in the dynamic table.
Probably yes.
Fixed in .
May we update "Huffman-coded" with "Huffman encoded" in this text to match other uses? Original: They begin with a single bit flag, denoted as 'H' in this document (indicating whether the string is Huffman-coded), followed by the Length encoded as a 7-bit prefix integer, and finally Length bytes of data.
Fixed in .
Change:
It returns an authenticator request, which is a sequence of octets that includes a CertificateRequest message. <del> "get context", which takes as input </del> <ins> 5.2. The "get context" API takes as input: </ins> authenticator It returns the certificate_request_context. <del> "authenticate", which takes as input: </del> <ins> 5.3. The "authenticate" takes as input: </ins> a set of certificate chains and associated extensions (OCSP, SCT, etc.)

Discussion:
There are lots of changes here. I did stage this as separate commits to some extent, so feel free to cherry-pick. There is one maybe-technical change here. It wasn't clear about the precedence between handshake and authenticator request for extensions. I've chosen to be clear about this and say that if the authenticator request exists, then it is the only thing that matters. That's 8c0b166. I can drop that from the CL and do that separately if you prefer.
Thanks for the comments. The technical clarification you made is the correct one, the request supersedes the handshake for extension choices if present.
Change:
connection attempts using any new QUIC versions that begin connections with a short header. <del> If a Retry Service is integrated with a QUIC-LB compliant load </del> <ins> If a Retry Service is integrated with a QUIC-LB routable load </ins> balancer, it can verify that the Destination Connection ID is <del> compliant, and only admit non-Initial packets with compliant DCIDs.  As the Connection ID encoding is invariant across QUIC versions, the Retry Service can do this for all short headers. </del> <ins> routable, and only admit non-Initial packets with routable DCIDs. As the Connection ID encoding is invariant across QUIC versions, the Retry Service can do this for all short headers. </ins> Nothing in this section prevents Retry Services from making basic syntax correctness checks on packets with QUIC versions that it understands (e.g., enforcing the Initial Packet datagram size minimum <del> in version 1) and dropping packets that are not compliant with the </del> <ins> in version 1) and dropping packets that are not routable with the </ins> QUIC specification. 7.2.

Discussion:
and
I'd suggest 'Fallback' or another word than arbitrary. A definition of Arbitrary is: "Based on random choice or personal whim, rather than any reason or system." In fact, there are sensible constraints on this algorithm to ensure routing works correctly for non-compliant CIDs and connections don't fail.
Agreed.
In PR I suggested non-routable, though I realize non-conformant may also be an option. The sentence which caused me to suggest non-routable is: URL I'm happy to write a PR if others find non-compliant potentially confusing as well.
I like it. Let's go with it.
Thanks, this is a lot easier to read for me.
Change:
Public keys used in the protocol are opaque values in a format defined by the ciphersuite, using the following types: <ins> Cryptographic algorithms are indicated using the following types: </ins> 5.5.1. This ciphersuite uses the following primitives:

Discussion:
Need some actual values here for interop. Signature scheme values are a subset of those in RFC 8446. NAME - Do you think we should go ahead and define the higher-security-level ciphersuites as well as signature algorithms?
Looks good to me! We can always re-introduce Ed448 with X448 later.
Change:
As discussed in challenge, clients SHOULD discard any context-bound tokens upon flushing cookies or changing networks, to prevent an <del> Origin using the redemption context state as a cookie to recognize </del> <ins> origin using the redemption context state as a cookie to recognize </ins> clients. Applications SHOULD constrain tokens to a single origin unless the

Discussion:
NAME please have a look!
From Ted Hardie in Vienna.
We should also clarify more explicitly how the client uses the origin name field for validating the context it is in.
Leaning towards allowing the being able to be a list of hostnames, with comma separation.
+1 to csv. We think this keeps the client impl's simple while allowing for the added flexibility of origin sets.
Might also have to say something about ignoring whitespace vs and then maybe just whitespace is the separator?
While I can understand the appeal, I'm not yet convinced we should do this until we have a use case and have thought through the possible privacy impacts.
perfect!
Change:
The following elements are defined: <del> identifies the profile being defined. </del> <ins> identifies the profile being defined (default: "").  If present, this key MUST contain a hex-encoded sequence of 0-255 bytes (the "profile ID").  IDs whose decoded length is 4 bytes or less are reserved (see reserved-profiles).  When a reserved value is used (including the default value), other keys MUST NOT appear in the template, and a client MUST NOT accept the template unless it recognizes the ID. </ins> indicates that both sides agree to the single TLS version specified by the given integer value (772 == 0x0304 for TLS 1.3).

Discussion:
This change also reserves short profile IDs for "well-known" use. Fixes URL
Can we please try to resolve this question soon to unblock implementation?
NAME NAME Any objection to merging this?
The template says it's an integer (in what range?), but the ClientHello says it's 0-255 bytes. I think it's probably easiest to say it's a string of 0-255 bytes, with the empty string reserved to mean "no template". I guess if you want to get fancy you could reserve all 1-4 byte strings.
Agreed. If you want to send a PR, I wouldn't object.
This LGTM.
Change:
address, potentially followed by a transport layer port number, are usually used in the authority component for the "http" and "coap" schemes.  The path and query contain data to identify a resource <del> within the scope of the URI's scheme and naming authority.  The path is hierarchical; the query is non-hierarchical.  The fragment allows to refer to some portion of the resource, such as a section in an HTML document. </del> <ins> within the scope of the URI's scheme and naming authority.  The fragment allows to refer to some portion of the resource, such as a section in an HTML document. </ins> For RESTful IoT applications, typical schemes include "https", "coaps", "http", and "coap".  These refer to HTTP and CoAP, with and

Discussion:
Removed "path is hierarchical query not" comment. Added note about query component order being unspecified.
This addresses issue
URL
Fixed in PR Hi, In reading draft-keranen-t2trg-rest-iot-01 I note the following: It is my understanding that this statement is subject to debate. Certainly some RESTful APIs assign hierarchical semantics to the path. For example, /foo may refer to a "collection-style" resource and /foo/bar may refer to a resource within that collection. However, is this a necessary requirement? From my perspective, this could potentially limit extensibility as future revisions of a RESTful API may, for instance, wish to insert a resource "between" /foo and /foo/bar. If the resources themselves are truly self-describing, containing links to "subordinate" resources, then the path portion of the URI can become an opaque identifier and backward compatibility in this hypothetical RESTful API could be maintained. Likewise, I have seen RESTful APIs where the order of the elements in the query portion of the URI matters (particularly if a given element occurs multiple times). I would suggest staying silent on the semantics of these parts of the URI or noting that they MAY be hierarchical / non-hierarchical. Thanks, Robby