jiebi/CodeConvo huggingface dataset:
Change:
CAs that use ACME to automate issuance will need to ensure that their servers perform all necessary checks before issuing. <del> 10.  References </del> <ins> 10. </ins> <del> 10.1.  URIs </del> <ins> There are certain factors that arise in operational reality that operators of ACME-based CAs will need to keep in mind when configuring their services. [[ TODO: Other operational considerations ]] 10.1. In many cases, TLS-based services are deployed on hosted platforms that use the Server Name Indication (SNI) TLS extension to distinguish between different hosted services or "virtual hosts". When a client initiates a TLS connection with an SNI value indicating a provisioned host, the hosting platform routes the connection to that host. When a connection come in with an unknown SNI value, one might expect the hosting platform to terminate the TLS connection.  However, some hosting platforms will choose a virtual host to be the "default", and route connections with unknown SNI values to that host. In such cases, the owner of the default virtual host can complete a TLS-based challenge (e.g., "tls-sni-01") for any domain with an A record that points to the hosting platform.  This could result in mis-issuance in cases where there are multiple hosts with different owners resident on the hosting platform. A CA that accepts TLS-based proof of domain control should attempt to check whether a domain is hosted on a domain with a default virtual host before allowing an authorization request for this host to use a TLS-based challenge.  A default virtual host can be detected by initiating TLS connections to the host with random SNI values within the namespace used for the TLS-based challenge (the "acme.invalid" namespace for "tls-sni-01"). 11.  References 11.1.  URIs </ins> [1] https://github.com/ietf-wg-acme/acme

Discussion:
At the IETF meeting, we discussed the possibility of simplifying the "tls-sni-01" challenge to remove the iterations, as suggested in . NAME noted that if we were going to do that, we should recommend some ways for CAs to check whether a default vhost was in play. This PR adds such a note, and creates an "Operational Considerations" section for any future such notes that might come along.
Change:
unsupported parameters to "PrivateToken" authentication credentials MUST be ignored. <del> Clients present this Token structure to Origins in a new HTTP request </del> <ins> Clients present this Token structure to origins in a new HTTP request </ins> using the Authorization header as follows: For token types that support public verifiability, origins verify 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:
basic keep-alive function.  In contrast, Ping and Pong messages are a bidirectional exchange. <del> Upon receipt of a Ping message, a single Pong message is returned with the identical token.  As with all Signaling messages, the </del> <ins> Upon receipt of a Ping message, the receiver MUST return a Pong message with an identical token in response.  Unless there is an option with delaying semantics such as the Custody Option, it SHOULD respond as soon as practical.  As with all Signaling messages, the </ins> recipient of a Ping or Pong message MUST ignore elective options it does not understand.

Discussion:
Corrected title for (leaving open while we discuss examples) Corrected version for new since-draft section
It only has examples of Ping and Pong. (It would probably help to have an example of an initial CSM exchange.)
Or perhaps eliminate the examples? I note that RFC7252 does not include Option examples.
I'd rather do the work to include an initial CSM exchange. Just not sure I can get to that tomorrow. (This kind of example is counter-intimidating — after all the verbiage you see that it is all really very simple...)
I'm not sure that it was intimidating although I like counter-intimidating. It was certainly not a source of confusion during WGLC that then required clarification in examples. I worry about simply adding noise. And if pursued further, we should avoid Default-Uri-Host which would leave Max-Message-Size and Block-wise Transfer.
I corrected the title in . I'm won't fixing the suggestion for CSM examples based on my previous comment. This can be revisited if there's any related confusion during subsequent reviews.
Change:
that conveyed the severity of the message in previous versions of TLS.  In TLS 1.3, the severity is implicit in the type of alert being sent, and the 'level' field can safely be ignored.  The <del> "close_notify" alert is used to indicate orderly closure of the connection.  Upon receiving such an alert, the TLS implementation SHOULD indicate end-of-data to the application. </del> <ins> "close_notify" alert is used to indicate orderly closure of one direction of the connection.  Upon receiving such an alert, the TLS implementation SHOULD indicate end-of-data to the application. </ins> Error alerts indicate abortive closure of the connection (see error- alerts).  Upon receiving an error alert, the TLS implementation

Discussion:
Currently TLS 1.3 specifies closenotify in the same way that TLS 1.2 did. I believe that has issues and this might be the right time to fix them. The purpose of closenotify is to protect against data truncation attacks, each side is required to send closenotify before closing the write side of the transport connection so the other side knows that the data was not truncated. As such, closenotify only needs half-close semantics to prevent truncation. However, the specification contains the following text: > This means that an application-layer client can't send a query then close their write transport when they know that they're done, because the server would terminate the TLS session before sending the reply. On top of this, when the server receives the closenotify, it may have already sent part of the reply (or wrote it to the socket send buffer) so the responding closenotify would in effect be inflicting a truncation attack on the client. This doesn't make much difference for HTTP because clients already don't close their write transport after sending a reply, however having the option do do this could allow innovation in new protocols that can define the semantics of when they use closenotify. An example is DNS PUSH: URL A proposal to solve this problem would be to give closenotify half-close semantics: we keep the requirements that a closenotify be sent before closing the transport, and that any data received after a closenotify is ignored, but we simply remove the requirement to immediately reply with a close_notify. This has the advantage that current implementations are already compliant but future ones can leverage this improvement.
Change:
a stub account object containing the "contact" field and optionally the "terms-of-service-agreed" field. <del> The server MUST ignore any values provided in the "key", and "orders" fields in account bodies sent by the client, as well as any other fields that it does not recognize.  If new fields are specified in the future, the specification of those fields MUST describe whether they can be provided by the client. </del> <ins> The server MUST ignore any values provided in the "orders" fields in account bodies sent by the client, as well as any other fields that it does not recognize.  If new fields are specified in the future, the specification of those fields MUST describe whether they can be provided by the client. </ins> In general, the server MUST ignore any fields in the request object that it does not recognize.  In particular, it MUST NOT reflect

Discussion:
The client knows what its public key is, because it has to have access to the private key in order to sign new-account requests or updates to the account resource. So this field serves no purpose.
Has this been discussed on list? I'm concerned that we're removing information that could be valuable for debugging client issues. There's no harm in keeping this; the server has to store this information anyway.
Yep, this was discussed on-list. I can say that as a client developer, I've never found this field useful. Clients need to be able to successfully serialize a jwk in order to speak the protocol. Also, I have no objection to servers including this as an extra field, but it seems wrong to normatively require it when it serves no purpose.
For the record where it was available for discussion. For me, the observation that you need the private key to get an account object is dispositive. There's not even debugging utility here. So I'm OK to merge. Right now, account objects echo back the public key associated with the account, in the "key" field. However, this is redundant since the only request types that can return an account object are signed by the corresponding private key, so the client necessarily knows what its public key is. Removing this simplifies the spec somewhat. URL Thoughts?
Change:
A client could have received and acknowledged a Handshake packet, causing it to discard state for the Initial packet number space, but not sent any ack-eliciting Handshake packets.  In this case, the PTO <del> is set from the current time. </del> <ins> timer is armed from the time that the Initial packet number space is discarded. </ins> 6.2.3.

Discussion:
This is a rephrase of NAME suggestion.
The pseudo code says the following: With the change introduced in , the spec says the following for the time from which the timer should be armed if there are no outstanding packets in the Handshake packet number space:
This code is called from where Initial keys are discarded, so I believe it still matches the text, which only discusses the "(has handshake keys)" case.
That being said, it feels odd we mention one case of using now() and not the other, so I updated PR
This paragraph does not really provide any context that would allow you to infer what the "current time" is. Based on the pseudocode, this time is when SetLossDetectionTimer() is invoked, but that covers a range of cases: When a packet is received and the endpoint is at its anti-amplification limit When an in-flight packet is sent When an ACK is received When the loss detection timer pops When a packet number space is discarded Of these, the "current time" clause only really applies to the last two, and the last one is the real baseline (because the other only matters if the first was set). I think that this can be more precisely worded to say "In this case, the PTO is set from the time at which the Initial packet number space is discarded." That's far more direct, but I would like others to check my work to ensure that it catches all the cases properly.
Setting the time from when the Initial PN space is discarded is a good clarification, and conveniently it lines up with the pseudocode. The pseudocode for OnPacketNumberSpaceDiscarded(pn_space) calls SetLossDetectionTimer().
There are actually two cases now() is used, so we can't solely rely on handshake keys being discarded. See for a larger change.
This is good, but I wouldn't talk about "current time" at all.
Change:
bidirectional exchange. Upon receipt of a Ping message, the receiver MUST return a Pong <del> message with an identical token in response.  Unless there is an option with delaying semantics such as the Custody Option, it SHOULD respond as soon as practical.  As with all Signaling messages, the recipient of a Ping or Pong message MUST ignore elective options it does not understand. </del> <ins> message with an identical token in response.  Unless the Ping carries an option with delaying semantics such as the Custody Option, it SHOULD respond as soon as practical.  As with all Signaling messages, the recipient of a Ping or Pong message MUST ignore elective options it does not understand. </ins> Ping and Pong messages are indicated by the 7.02 code (Ping) and the 7.03 code (Pong).

Discussion:
s/Unless there is an option with delaying semantics/Unless the PING carries an option with delaying semantics/
Change:
Pseudo-header fields are not HTTP fields.  Endpoints MUST NOT generate pseudo-header fields other than those defined in this <del> document, except as negotiated via an extension; see extensions. </del> <ins> document; however, an extension could negotiate a modification of this restriction; see extensions. </ins> Pseudo-header fields are only valid in the context in which they are defined.  Pseudo-header fields defined for requests MUST NOT appear

Discussion:
Taken from NAME suggestion on the list.
On the mailing list NAME raised a question about pseudo-headers. That discussion seemed to identify that HTTP/3 oversteps the mark by saying that psuedo-headers are extensible. We can make an editorial change to bring this back to something equivalent to what RFC 7540 says. See .
Conversation evolved, I''ve created a PR that takes Mike's suggestion.
Change:
"token_type" is a 2-octet integer, which matches the type in the challenge. <del> "token_key_id" is the least significant byte of the "key_id". </del> <ins> "token_key_id" is the least significant byte of the "key_id" in network byte order (in other words, the last 8 bits of "key_id"). </ins> "blinded_msg" is the Nk-octet request defined above.

Discussion:
Is this the most exact way to put this? For byte arrays like a hash, I generally don't think of it as being network- or host- byte order. Do we have other docs that refer to stuff like this that we can crib from?
Nothing comes to mind right now, but I'm happy to look at alternatives.
Works for me =)
We should be explicit about what this means: This means that the byte is the last/rightmost byte of the hash, in order. Misinterpretation of this caused some confusion in interop.
Here's an attempt at saying this in other words to be extra clear?
Change:
4.2.1. <del> Because DTLS records could be reordered, a record from epoch 1 may be received after epoch 2 has begun.  In general, implementations SHOULD discard packets from earlier epochs, but if packet loss causes noticeable problems implementations MAY choose to retain keying material from previous epochs for up to the default MSL specified for TCP RFC0793 to allow for packet reordering.  (Note that the intention here is that implementers use the current guidance from the IETF for MSL, as specified in RFC0793 or successors not that they attempt to interrogate the MSL that the system TCP stack is using.) </del> <ins> Because DTLS records could be reordered, a record from epoch M may be received after epoch N (where N > M) has begun.  In general, implementations SHOULD discard packets from earlier epochs, but if packet loss causes noticeable problems implementations MAY choose to retain keying material from previous epochs for up to the default MSL specified for TCP RFC0793 to allow for packet reordering.  (Note that the intention here is that implementers use the current guidance from the IETF for MSL, as specified in RFC0793 or successors not that they attempt to interrogate the MSL that the system TCP stack is using.) </ins> Conversely, it is possible for records that are protected with the new epoch to be received prior to the completion of a handshake.  For

Discussion:
NAME NAME
Well, clients can recover by tearing down the connection and starting over.
Sure, sure. I think this was in the context of a "single" connection. Perhaps it's not that important to clarify?
I'll add text.
I think the only comment that's left to be addressed is this: Perhaps what's missing is precisely that clarifying statement. Namely, that clients which find themselves in such a situation cannot recover.
Change:
Authentication: The server side of the channel is always authenticated; the client side is optionally authenticated. Authentication can happen via asymmetric cryptography (e.g., RSA <del> RSA, the Elliptic Curve Digital Signature Algorithm (ECDSA) ECDSA, </del> <ins> RSA, the Elliptic Curve Digital Signature Algorithm (ECDSA) DSS, </ins> or the Edwards-Curve Digital Signature Algorithm (EdDSA) RFC8032) or a symmetric pre-shared key (PSK).

Discussion:
FIPS 186-4 is obsolete Curve definitions have moved to the new NIST SP 800-186 ANSI X9.62 is behind a paywall and should be avoided if possible. References behind paywall can not be accessed by most readers. This makes it harder to implement and to evaluate the security of the protocol. FIPS 186-5 removed the dependency on ANSI X9.62 and defines ECDSA itself. Point validation is defined in the new NIST SP 800-186.
Change:
The "chunked" transfer encoding defined in Section 4.1 of RFC7230 MUST NOT be used. <ins> If a DATA frame is received before a HEADERS frame on a either a request or push stream, the recipient MUST respond with a connection error of type HTTP_UNEXPECTED_FRAME (errors). </ins> Trailing header fields are carried in an additional HEADERS frame following the body.  Senders MUST send only one HEADERS frame in the trailers section; receivers MUST discard any subsequent HEADERS

Discussion:
reincarnated, because I messed up. Sorry, NAME
LGTM but don't forget push
Change:
records under the domain name to respond to specific connection attempts utilizing the Server Name Indication extension RFC6066.  The server verifies the client's challenge by accessing the reconfigured <del> server and verifying a particular challenge certificate is presented. </del> <ins> TLS server and verifying a particular challenge certificate is presented. </ins> The string "tls-sni-02"

Discussion:
As pointed out by NAME on the ACME mailing list there are a few places where there was some potential ambiguity about what "server" meant. This PR is the result of a once-through pass looking for places where we could be more specific when saying "server". In most cases the default definition of "server" from the Terminology section applied and no change was made. I attempted to clarify any usage of "server" that wasn't qualified sufficiently to differentiate from the ACME server.
Change:
frame.  A client sends MAX_PUSH_ID frames to control the number of pushes that a server can promise.  A server SHOULD use Push IDs sequentially, beginning from zero.  A client MUST treat receipt of a <del> push stream with a Push ID that is greater than the maximum Push ID as a connection error of type H3_ID_ERROR. </del> <ins> push stream as a connection error of type H3_ID_ERROR when no MAX_PUSH_ID frame has been sent or when the stream references a Push ID that is greater than the maximum Push ID. </ins> The Push ID is used in one or more PUSH_PROMISE frames (frame-push- promise) that carry the header section of the request message.  These

Discussion:
Probably editorial since this is what was previously intended, but still touching a MUST.
states: The case when the client has not sent a MAXPUSHID frame is not covered. (In this case, the client should treat the receipt of any frame with a Push ID as an error.)
There is some other text that kinda marks the error case: One interpretation is that since any value of ID is greater than , then the error condition holds. But I agree with Dmitri that we could probably make this clearer with some editorializing.
That's a big stretch. Does it hold in languages that have a , such as JavaScript? E.g., can one write ?
Since it starts as unset, and MAXPUSHID can only increase the value then in this world, 0 must be greater than unset
What is "unset?" &lt;DmitriMode>If 0 is a valid value, then "unset" means , which is not smaller than 0. That is, it is not true that , which is what the text says.&lt;/DmitriMode>
Sure, but then it makes it very hard to send a MAXPUSHID that doesn't decrease the value. I think we agree that it would help the doc to fix your original nitpick.
Unset is negative one? The frame sets a boolean? This seems easy enough to implement in practice, but you're correct that the doc is effectively using a nullable type. I see a couple possible doc fixes. The most minimal change is to simply state that it is also an error to receive anything that uses a Push ID if no MAXPUSHID frame has been sent. That's compatible and consistent with the intent of the current design. Alternatively, we could define MAXPUSHID to tell the recipient how many Push IDs they can use; 0 is the initial value, and sending 0 leaves push disabled. That's consistent with QUIC's MAXSTREAMS et al. but would be a breaking change.
I vote for the simplest approach:
+1 let's keep it simple
Editorial?
Yes, this is an editorial issue.
Change:
HTTP can make use of already-deployed caching infrastructure. Unreliable media delivery using RTP and other UDP-based protocols is <del> also discussed in ultralow, unreliable, udp-behavior, and hop-by-hop- encrypt, but it is difficult to give general guidance for these applications.  For instance, when loss occurs, the most appropriate response may depend on the type of codec being used. </del> <ins> also discussed in ultralow, udp-behavior, and hop-by-hop-encrypt, but it is difficult to give general guidance for these applications.  For instance, when loss occurs, the most appropriate response may depend on the type of codec being used. </ins> 3.

Discussion:
I've edited NAME suggested text a bit, but the proposed structure was WAY more coherent than what I had assembled. Thank you for that!
From NAME Unsure whether this section really belongs to section 5 based on its contents vs. section 5 title. Especially when placed just before section 6, which is about transport protocols.
Hi, NAME I'm actually pretty sure Section 5.7 doesn't below in Section 5. :rofl: I moved the text from Section 5.7 INTO the section on UDP in Section 6, with minimal editing. I need to think about whether I need to do some more editing, but at least it's where it ought to be now.
Change:
If the client wishes to update this information in the future, it sends a POST request with updated information to the registration <del> URI.  The server MUST ignore any updates to the "key", "authorizations, or "certificates" fields, and MUST verify that the request is signed with the private key corresponding to the "key" field of the request before updating the registration. </del> <ins> URI.  The server MUST ignore any updates to the "key", or "applications" fields or any other fields it does not recognize.  The server MUST verify that the request is signed with the private key corresponding to the "key" field of the request before updating the registration. </ins> For example, to update the contact information in the above registration, the client could send the following request:

Discussion:
In the "applications" field of the registration resource is described in great detail. This is confusing for two reasons: both the text and the example registration object are still using the "authorization" term that applications replace. the text is written as if the applications should be directly embedded in the registration object returned. This PR addresses both issues by describing the "applications" field as an array of application URIs that the client can fetch. The example "registration" object is updated accordingly. The note indicating a server SHOULD include pending applications and SHOULD NOT include invalid applications remains as-is. The note indicating a server MAY return an incomplete list is removed - it is more complicated and with only URIs being returned, likely an unneeded optimization. Finally, in there are three fields that must be ignored by the server in a registration body: key, authorizations and certificates. This should be "key" and "applications" and is updated accordingly.
NAME feedback addressed, and conflicts w/ master resolved. Thanks for the :eyes: !