jiebi/CodeConvo huggingface dataset:
Change:
disadvantage that the server has to retain a table of all the server names it supports.]] <ins> A list of extensions that the client can take into consideration when generating a Client Hello message.  The format is defined in I-D.ietf-tls-tls13; Section 4.2.  The purpose of the field is to provide room for additional features in the future; this document does not define any extension. </ins> The semantics of this structure are simple: any of the listed keys may be used to encrypt the SNI for the associated domain name.  The cipher suite list is orthogonal to the list of keys, so each key may

Discussion:
At the moment, there is no extensibility in ESNIKeys. That means that if we want to add additional attributes, we would be forced to define a new DNS record that gets queried simultaneously. I think we do not want to do that. Hence the extensions field. The text is tentative; please feel free to change in any ways.
LGTM.
With merged, I wonder if the ESNIKeys struct should just be renamed to something not specific to ESNI, but something more like "generic TLS config in DNS" so that it can be more cleanly reused by unrelated features. "ServerConfiguration" comes to mind from the early TLS 1.3 days.
If we were to re-use these keys for other purposes, that seems fine. However, I'm not sure we want to do that. Semi-static keys, for example, should ideally be separate.
The keys yes, but I imagine the extensions field can hold "arbitrary" data, so while the keys would be ESNI-specific, you could also include extensions that have nothing to do with ESNI.
Thinking about this some more, this would also require changing the "_esni." prefix to something else. In any case I can see how this might be out of scope for this spec. In the end it's a matter of deciding whether future TLS extensions that need similar DNS records, should be able to reuse the same structure (so no additional TXT record with its own prefix would be required), or if they should define their own structure (and have a separate TXT record). I'm happy to close this if it goes too much out of scope.
Right, I think it's verging on being out of scope. What do others think? NAME NAME
My preference goes to keeping the name as-is, considering the fact that the role of ESNIKeys is (at least for the moment) to negotiate properties between the client and the fronting server (not the hidden server), and that the only property we need to negotiate between the two is the information necessary for ESNI protection. It is true that the DNS record can covey properties related to the hidden server (as you know, I've argued for using it to carry the server certificate chain). But IMO that's a change of concept, and I prefer keeping the concept simple for the time being.
Ok.
Change:
0-RTT data to ensure that an application is always aware that it is sending or receiving data that might be replayed. <del> The same warnings apply to any use of the early_exporter_secret. </del> <ins> The same warnings apply to any use of the early_exporter_master_secret. </ins> The remainder of this document provides a detailed description of TLS.

Discussion:
Make the variable names of various secrets correspond to the labels used for Derive-Secret(). This is not a wire format change, but just a change in the internal variable names.
NAME NAME you see any misses here?
The legends for the message flows still say "trafficsecretN" for the "[]" parts. Also, "Updating Traffic Keys and IVs" still uses "trafficsecretN" in the formula and text prior to it.
In the key schedule
Change:
9. <ins> One goal of this design is that independent client requests are only linkable by the chosen KeyConfig.  The oblivious proxy and request resources can link requests using the same KeyConfig by matching KeyConfig.key_id.  The oblivious proxy can also link requests using the public key corresponding to KeyConfig.key_id.  The proxy cannot determine precisely which public key was used to encapsulate a request, given that multiple public keys may have matching key identifiers. Request resources are capable of linking requests depending on how KeyConfigs are produced by servers and discovered by clients. Specifically, servers can maliciously construct KeyConfigs to track individual clients.  While KeyConfig discovery is outside the scope of this specification, clients should consider this tracking vector in deployments.  Applications using this design should provide accommodations to mitigation this tracking vector. 10. </ins> Please update the "Media Types" registry at https://www.iana.org/assignments/media-types [1] with the registration information in media-types for the media types "message/ ohttp-req", "message/ohttp-res", and "application/ohttp-keys". <del> 10.  References </del> <ins> 11.  References </ins> <del> 10.1.  URIs </del> <ins> 11.1.  URIs </ins> [1] https://www.iana.org/assignments/media-types

Discussion:
A server that wants to undermine this process can ensure that clients are provided with individual keys. Though there is a limited number of key identifiers (though see also ), a server could extend the number of identifiers with a little bit of trial decryption. Or the server could just use this ability selectively. Though the draft deliberately avoids talking about how clients learn about keys, we might talk about the implications of acquiring keys from servers. If the server is responsible for issuing keys, then the server can target individuals with specific keys. NAME suggests that maybe we could have the proxy provide keys. This is not a bad way to deal with this problem, though it places more trust in the proxy as the proxy now needs to be trusted not to provide a key for which it has the secret key. That might still work if the key could be further authenticated by the server, but that's a rabbit hole of its own.
Change:
subject name, or in an extensionRequest attribute RFC2985 requesting a subjectAltName extension. <del> The values provided in the CSR are only a request, and are not guaranteed.  The server SHOULD return an error if it cannot fulfil the request as specified, but MAY issue a certificate with contents other than those requested, according to its local policy (e.g., removing identifiers for which the client is not authorized). </del> <ins> The server MUST return an error if it cannot fulfil the request as specified, and MUST NOT issue a certificate with contents other than those requested.  If the server requires the request to be modified in a certain way, it should indicate the required changes using an appropriate error code and description. </ins> It is up to the server's local policy to decide which names are acceptable in a certificate, given the authorizations that the server

Discussion:
As discussed at IETF 95, the server should fail a new-cert request if it cannot fulfill it precisely. It must not modify the request to something it is willing to fulfill.
We need to clarify when an ACME server can ignore attributes in a request that it doesn't like, and when it should ignore them and proceed. For example, if a requested validity date is longer than the policy, should it error back or just ignore that attribute and issue a cert good for as long as it wants? That seems okay. But what about an unsupported request for issuance in the future? Ignoring that seems wrong, and risky.
I think in general ACME should take the approach of refusing to issue a cert if requested parameters (dates, or extensions) are unacceptable. It's cheap for the client to re-request with acceptable parameters, assuming the error message is detailed enough.
Scoping this down to new-certificate requests, since there's not really enough latitude in the other types of request to cause this problem.
Agreed in B.A. to fail, fail, fail, but return information helpful to a human, explicitly not machine-recoverable. It may be possible to give a trivial amount of altitude (e.g. 90 days--will it not be okay if 90-days minus 15 seconds is given?)
Change:
ensure that nothing has been tampered with or substituted in a way that would change the nature of the request. <del> When used in the GNAP delegation protocol, these key binding mechanisms allow the AS to ensure that the keys presented by the RC in the initial request are in control of the party calling any follow-up or continuation requests.  To facilitate this requirement, all keys in the initial request request-key MUST be proved in all continuation requests continue-request and token management requests token-management, modulo any rotations on those keys over time that the AS knows about.  The AS MUST validate all keys request-key or referenced in an ongoing request for each call within that request. </del> <ins> When used for delegation in GNAP, these key binding mechanisms allow the AS to ensure that the keys presented by the RC in the initial request are in control of the party calling any follow-up or continuation requests.  To facilitate this requirement, all keys in the initial request request-key MUST be proved in all continuation requests continue-request and token management requests token- management, modulo any rotations on those keys over time that the AS knows about.  The AS MUST validate all keys request-key or referenced in an ongoing request for each call within that request. </ins> [[ See issue #105 [78] ]]

Discussion:
I attempted to rephrase all occurrences of the redundant "GNAP protocol" in a way that made sense. Most of the time it was changing "the GNAP protocol" to just "GNAP", but there are a few cases where it sounded weird and required some more context.
Change:
10.2. <del> Supporting optional record digests and trial decryption opens oneself up to DoS attacks.  Specifically, an adversary may send malicious ClientHello messages, i.e., those which will not decrypt with any known ECHO key, in order to force decryption.  Servers that support this feature should, for example, implement some form of rate limiting mechanism to limit the damage caused by such attacks. </del> <ins> Optional record digests may be useful in scenarios where clients and client-facing servers do not want to reveal information about the client-facing server in the "encrypted_client_hello" extension.  In such settings, servers must perform trial decrypt upon receipt of an empty record digest, which may exacerbate DoS attacks.  Specifically, an adversary may send malicious ClientHello messages, i.e., those which will not decrypt with any known ECHO key, in order to force wasteful decryption.  Servers that support this feature should, for example, implement some form of rate limiting mechanism to limit the damage caused by such attacks. </ins> 10.3.

Discussion:
Addresses . cc NAME
And possibly also include a bit inside ESNIConfig that tells clients whether or not to populate record_digest. (See URL for some relevant definitions.)
Works for me.
Change:
the aggregators is malicious.  Differential privacy is a strong privacy definition, and protects users in extreme circumstances: Even if an adversary has prior knowledge of every input in a batch except <del> for one, that one record is still protected. </del> <ins> for one, that one record is still formally protected. [OPEN ISSUE: While parameters configuring the differential privacy noise (like specific distributions / variance) can be agreed upon out of band by the aggregators and collector, there may be benefits to adding explicit protocol support by encoding them into "PDAParams".] </ins> 8.6.

Discussion:
Differential privacy can protect against attacks where a portion of the input data is known a priori, or when the size of a batch is small. This PR adds DP as an optional mitigation for PDA deployments and lists where it helps mitigate various threats. Additionally: Removes a false statement that revealing user input does not compromise other users' privacy. This is not necessarily the case (e.g. imagine if the batch size is 2 or if many users reveal their input). Removes a statement that clients revealing their inputs is outside the threat model (is this still relevant?)
Change:
"WithIPv6Address" with an unscoped address and "WithInterface " together. <del> An Endpoint cannot have multiple identifiers of a same type set. That is, an endpoint cannot have two IP addresses specified.  Two separate IP addresses are represented as two Endpoint Objects.  If a Preconnection specifies a Remote Endpoint with a specific IP address set, it will only establish Connections to that IP address.  If, on the other hand, the Remote Endpoint specifies a hostname but no addresses, the Connection can perform name resolution and attempt using any address derived from the original hostname of the Remote Endpoint.  Note that multiple Remote Endpoints can be added to a Preconnection, as discussed in add-endpoints. </del> <ins> An Endpoint MUST NOT be configured with multiple identifiers of the same type.  For example, an endpoint cannot have two IP addresses specified.  Two separate IP addresses are represented as two Endpoint Objects.  If a Preconnection specifies a Remote Endpoint with a specific IP address set, it will only establish Connections to that IP address.  If, on the other hand, the Remote Endpoint specifies a hostname but no addresses, the Connection can perform name resolution and attempt using any address derived from the original hostname of the Remote Endpoint.  Note that multiple Remote Endpoints can be added to a Preconnection, as discussed in add-endpoints. </ins> The Transport Services system resolves names internally, when the Initiate(), Listen(), or Rendezvous() method is called to establish a

Discussion:
I'm happy to do this! But while we're at it, isn't the "a" a bit awkward? Wouldn't this read even better as: "An Endpoint MUST NOT be configured with multiple identifiers of the same type." I just pushed that suggestion.
URL This seems to me as a strong claim without using normative language. Shall we use normative language here?
Agree, although then I think we need to explain "set" so that we create an RFC2119 sentence with meaning when read on its own. Is this anywhere near: An Endpoint MUST NOT set multiple identifiers of the same type. And... is the /that is/ correct? or is this an example of something that is not allowed?
I'd say it's an example, although also the most likely such case. Suggest: replace "That is," with "Thus,"
If this is just an example then lets just be explicit about it.
I like the change. Is the English clunky, could it be: An Endpoint MUST NOT be configured with multiple identifiers of a same type.
Change:
identifiers.  This can in turn ease parsing and connection lookup, for example by having the length in question be a compile-time constant.  Such implementations MUST still be able to send CIDs of <del> different length to other parties.  Implementations that want to use variable-length CIDs are responsible for constructing the CID in such a way that its length can be determined on reception.  Note that there is no CID length information included in the record itself. </del> <ins> different length to other parties.  Since the CID length information is not included in the record itself, implementations that want to use variable-length CIDs are responsible for constructing the CID in such a way that its length can be determined on reception. </ins> In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session only.  There is no dedicated "CID update" message that allows new

Discussion:
Partly addresses
URL
Regarding: We could streamline that a bit: removing the affiliations (who knows which have become stale in the meantime?), and also Besides, is "task force" the right term? Would "QUIC CID design team" be a better designation? Robert Wilton has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Hi, I'm no DTLS expert, but I found the concepts/explanation in this document easy to follow. I was slightly confused by the requirement to encode the length in variable length CIDs, and had to read the relevant text a second time. As a suggestion, it might help if these two sentences were reworded the other way round: OLD: Implementations that want to use variable-length CIDs are responsible for constructing the CID in such a way that its length can be determined on reception. Note that there is no CID length information included in the record itself. NEW: Since the CID length information is not included in the record itself, implementations that want to use ... . One minor question. In the contributors, I noted that Jana is listed as being associated with Google, but it might be worth checking if that is still accurate. Regards. Rob
Change:
protocol between the Attester and Relying Party. However, like in the Passport model, an Attestation Result is still <del> consumed by the Relying Party and so the serialization format of the Attestation Result is still important.  If the Relying Party is a constrained node whose purpose is to serve a given type resource using a standard resource access protocol, it already needs the parser(s) required by that existing protocol.  Hence, the ability to let the Relying Party obtain an Attestation Result in the same serialization format allows minimizing the code footprint and attack surface area of the Relying Party, especially if the Relying Party is a constrained node. </del> <ins> consumed by the Relying Party.  Code footprint and attack surface area can be minimized by using a serialization format for which the Relying Party already needs a parser to support the protocol between the Attester and Relying Party, which may be an existing standard or widely deployed resource access protocol.  Such minimization is especially important if the Relying Party is a constrained node. </ins> 5.3.

Discussion:
Signed-off-by: Dave Thaler
The paragraph: seems to reshuffle the content of the preceding one. The two can be combined / streamlined.
Maybe: "However, like in the Passport model, an Attestation Result is still consumed by the Relying Party and so the ability to convey it in the same serialization format as the Evidence allows minimizing the code footprint and attack surface area, which is especially important if the Relying Party is a constrained node."
Personally, I like the new content here that elaborates on motivation and intent. Anyone else like to chime in here to have in impact on that expositional text?
The meaning of is wrong, i.e., format same as the Evidence. Instead the meaning is format same as the resource access protocol natively uses.
Change:
an optional authenticator request or certificate_request_context (from 0 to 255 bytes) <del> It returns the exported authenticator as a sequence of octets. Ideally, the logic for selecting the certificates and extensions to include in the exporter is implemented in the TLS library. Implementing this in the TLS library lets the implementer take advantage of existing extension and certificate selection logic. </del> <ins> It returns either the exported authenticator or an empty authenticator as a sequence of octets.  It is RECOMMENDED that the logic for selecting the certificates and extensions to include in the exporter is implemented in the TLS library.  Implementing this in the TLS library lets the implementer take advantage of existing extension and certificate selection logic. </ins> It is also possible to implement this API outside of the TLS library using TLS exporters.  This may be preferable in cases where the application does not have access to a TLS library with these APIs or when TLS is handled independently of the application layer protocol. <del> 5.4. </del> <ins> 6.4. </ins> The "validate" API takes as input:

Discussion:
URL you don't want to provide one. TLS allows Certificate to be empty, with a missing CertificateVerify and Finished as normal. That would be a nice change. Alternatively, we could insist on the using application managing this, but it seems like an authenticated refusal is nice.
Resolved in PR
Change:
untruncated answer send back such an answer; it can instead send back an HTTP error to indicate that it cannot give a useful answer. <ins> This protocol does not define any use for the "original_transport" optional parameter of the application/dns-udpwireformat media type. </ins> 10. Joe Hildebrand contributed lots of material for a different iteration

Discussion:
This is to address the issue of draft-ietf-dnsop-dns-wireformat-http needing to say what the original transport was. Covered on the mailing list March 25 and March 30.
What's the benefit of "original_" over just plain "transport"?
Change:
immediate-close). Endpoints MUST NOT exceed the limit set by their peer.  An endpoint <del> that receives a STREAM frame with a stream ID exceeding the limit it has sent MUST treat this as a stream error of type STREAM_LIMIT_ERROR </del> <ins> that receives a frame with a stream ID exceeding the limit it has sent MUST treat this as a connection error of type STREAM_LIMIT_ERROR </ins> (error-handling). Once a receiver advertises a stream limit using the MAX_STREAMS

Discussion:
This aligns section 4.5 with section 19.11's text: "An endpoint MUST terminate a connection with a STREAMLIMITERROR error if a peer opens more streams than was permitted."
I'm going to recommend calling this editorial on the basis that it reconciles this text with another MUST-level requirement. But I will leave the issue open for the chairs to make a design/editorial assessment and any resulting consensus call.
In most places in QUIC, if an error is clearly avoidable(ie: only a buggy implementation would do so), then we advise closing the connection with an error, not just closing the stream with an error. In section 4.5 of transport(URL) it says: "Endpoints MUST NOT exceed the limit set by their peer. An endpoint that receives a STREAM frame with a stream ID exceeding the limit it has sent MUST treat this as a stream error of type STREAMLIMITERROR" Came up in discussion of
As I commented in the updated PR description, section 19.11 already says this: "An endpoint MUST terminate a connection with a STREAMLIMITERROR error if a peer opens more streams than was permitted."
Reopening to keep this visible.
is effectively the proposal, correct?
Yes. It was editorial. So I merged it. But then this issue really isn't editorial.
Yes, I opened this issue, then found that text in section 19.11 in the doc said exceeding MAXSTREAMID was a connection error, so the PR ended up aligning the two sections.
In HTTP/3 Appendix A.4 it states : : HTTPREQUESTREJECTED (in {{http-error-codes}}) is used to indicate that a request was not processed. Otherwise, not applicable because QUIC handles stream management. A STREAMIDERROR at the QUIC layer is used for streams that are improperly opened. But STREAMIDERROR was removed in transport draft 17.
Since URL there are different error codes that the transport might use depending on error conditions (maybe STREAMSTATEERROR or maybe STREAMLIMITERROR). I'm inclined to simply omit the sentence.
Change:
or <del> of their array elements or member values, respectively.  The behaviour is unpredictable for objects with duplicate names.  Applied to other value types, it will select nothing. </del> <ins> of their array elements or member values, respectively.  Applied to other value types, it will select nothing. </ins> A relative path, beginning with "@", refers to the current array element or member value as the filter selector iterates over the

Discussion:
Centralize the text that explains how non-interoperable JSON may cause unpredictable behavior. This is a little clumsy as the sections to be referenced are currently unnumbered.
Solves a few "behaviours", too :-)
This centralizing approach is a good thing. I suggest to reuse the phrase "duplicate names" for better recognition of the wording in RFC8259, though is more general, as it addresses more than two.
There may be scope for fine-tuning the section cross-referencing, but this can be deferred to purely editorial activity