jiebi/CodeConvo huggingface dataset:
Change:
value for each response, keep a list of issued nonces, and strike nonces from this list as they are used. <del> 5.4.1. </del> <ins> 5.5.1. </ins> The "Replay-Nonce" header field includes a server-generated value that the server can use to detect unauthorized replay in future

Discussion:
As discussed (too ambiguously) at IETF 96, this refactor uses two nested JWS objects instead of one parallel JWS object. This preserves the pattern that every ACME message sent by the client is signed by exactly one account key, and saves clients from having to search through multiple signatures in the verification process.
Looking at the current mechanism in a little more detail, I have a few concerns with the parallel-signature approach that's there now: It's not clear which signature is by the old key and which is by the new key, and the new key doesn't sign over the old key. Both signatures have to include the parameter, so this request burns two nonces unnecessarily The server's JWS checking code now has to switch between validating one signature and two Lots of JWS implementations don't support multiple signatures If not for this, we could require the flattened JSON serialization You need a lot of duplication to deal with the copy/paste attacks (cf. ). (On the other hand, I like that both signatures cover the parameter; reduces replayability.) I would propose that we change the signatures from parallel back to serial, as illustrated below. It would cost a little bit of payload bloat (due to another layer of base64url encoding), but I think the benefits in terms of conceptual simplicity would be worth it.
Just noticed that if we keep to one signature per object, you can do nice stuff like this on the server:
Change:
non-probing packet with a new largest packet number on its preferred address, the server begins sending non-probing packets to the client exclusively from its preferred IP address.  It SHOULD drop packets <del> for this connection received on the old IP address, but MAY continue </del> <ins> for this connection received on the old IP address, but can continue </ins> to process delayed packets. The addresses that a server provides in the preferred_address

Discussion:
Barry Leiba said:
The other reference was: — Section 3.5 — An endpoint SHOULD copy the error code from the STOPSENDING frame to the RESETSTREAM frame it sends, but MAY use any application error code. I'm OK with changing to "can".
I don't think we need to do this; I've suggested changes on the PR.
Ok, let's merge this one, and I'll make a separate PR for the second comment.
Change:
an authenticator <del> It returns the certificate chain and extensions. </del> <ins> It returns the certificate chain and extensions and a status to indicate whether the authenticator is valid or not.  If the authenticator was empty - that is, it did not contain a certificate - the certificate chain will contain no certificates. </ins> <del> 6. </del> <ins> 7. </ins> This document has no IANA actions. <del> 7. </del> <ins> 8. </ins> The Certificate/Verify/Finished pattern intentionally looks like the TLS 1.3 pattern which now has been analyzed several times.  In the

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:
An HTTP/3 implementation can immediately close the QUIC connection at any time.  This results in sending a QUIC CONNECTION_CLOSE frame to <del> the peer; the error code in this frame indicates to the peer why the connection is being closed.  See errors for error codes which can be used when closing a connection. </del> <ins> the peer indicating that the application layer has terminated the connection.  The application error code in this frame indicates to the peer why the connection is being closed.  See errors for error codes which can be used when closing a connection in HTTP/3. </ins> Before closing the connection, a GOAWAY MAY be sent to allow the client to retry some requests.  Including the GOAWAY frame in the

Discussion:
This goes most of the way to solving my perceived problem. I do wonder if we should also add a little bit more text to section 8 in this paragraph under certain circumstances. Implementations need to consider the impact on outstanding requests before making this choice. Perhaps just a reference e.g. "Implementations need to consider the impact on outstanding requests before making this choice, see {immediate-application-closure}."
But that section doesn't discuss the impact on outstanding requests, and it seems irrelevant to this topic. Can you expand on the connection you see?
to me, the choice to promote a stream error to a connection error is the choice to promote it to an immediate application close. Therefore the present statement about "impact on outstanding requests" is really about how to do/decide on graceful close with GOAWAY. If that is not the case, then I don't understand what other consierations my endpoint should make
That text was added as a compromise, basically reminding implementations that choosing to blow up their connection will lose any requests in flight, so you should have a good reason.
NAME I'm going to go ahead and merge this, since it addresses the original issue and stands by itself. If you think we need additional text elsewhere, can you open a separate issue?
Sure thing, I'll review again
Draft 25 section 5.3 says: any time. This results in sending a QUIC CONNECTIONCLOSE frame to the peer; the error code in this frame indicates to the peer why the connection is being closed. This doesn't specifically tie down H3-initiated closure to only use the application variant of CONNECTIONCLOSE (0x1d). This gets a bit strange when combined with later guidance to use H3 error codes or treat unknown error codes as
Change:
TLS 1.3 server implementations which respond to a ClientHello with a client_version indicating TLS 1.2 or below MUST set the first eight <del> bytes of its Random value to the bytes 44 4F 57 4E 47 52 44 01.  TLS 1.3 clients receiving a TLS 1.2 or below ServerHello MUST check that the top eight octets are not equal to either this value or 44 4F 57 4E 47 52 44 00 (which SHOULD by used by TLS 1.2 servers which are negotiating TLS 1.1 or below).  If a match is found the client MUST </del> <ins> bytes of their Random value to the bytes: TLS 1.2 server implementations which respond to a ClientHello with a client_version indicating TLS 1.1 or below SHOULD set the first eight bytes of their Random value to the bytes: TLS 1.3 clients receiving a TLS 1.2 or below ServerHello MUST check that the top eight octets are not equal to either of these values. TLS 1.2 clients SHOULD also perform this check if the ServerHello indicates TLS 1.1 or below.  If a match is found the client MUST </ins> abort the handshake with a fatal "illegal_parameter" alert.  This mechanism provides limited protection against downgrade attacks over and above that provided by the Finished exchange: because the

Discussion:
Chairs have judged that there is consensus to merge, see: URL It looks like we have rough consensus to accept this PR. We should make sure we note the limitations that Karthink brought up for PSK and RSA, URL Procedurally, we should document the requirements for TLS 1.2 in a separate draft to update TLS 1.2 in parallel. This may be necessary to get us out of the situation where we have to update and obsolete a specification at the same time. Thanks, J&S , Eric Rescorla wrote:
Change:
7. Servers that support ECH play one of two roles, depending on the <del> payload of the "encrypted_client_hello" extension in the ClientHello: </del> <ins> payload of the "encrypted_client_hello" extension in the initial ClientHello: </ins> If "ClientECH.type" is "outer", then the server acts as a client- facing server and proceeds as described in client-facing-server to

Discussion:
The requirement to check the ClientHello for an inner ClientECH doesn't make sense because the entire section is already conditioned by observing an inner ClientECH. Also clarify that the client-facing vs. backend server dispatch happens at the initial ClientHello. Switching roles mid-connection will not work very well.
Change:
tls-sni-encryption provides a description of the problem space and some of the proposed techniques.  One of the more difficult problems is "Do not stick out" (I-D.ietf-tls-sni-encryption; Section 2.4): if <del> only hidden services use SNI encryption, then SNI encryption is a signal that a client is going to a hidden server.  For this reason, much recent work has focused on concealing the fact that SNI is being protected.  Unfortunately, the result often has undesirable performance consequences, incomplete coverage, or both. </del> <ins> only sensitive/private services use SNI encryption, then SNI encryption is a signal that a client is going to such a service.  For this reason, much recent work has focused on concealing the fact that SNI is being protected.  Unfortunately, the result often has undesirable performance consequences, incomplete coverage, or both. </ins> The design in this document takes a different approach: it assumes <del> that hidden servers will hide behind a provider (CDN, app server, etc.) which is able to activate encrypted SNI (ESNI) for all of the domains it hosts.  Thus, the use of encrypted SNI does not indicate that the client is attempting to reach a hidden server, but only that it is going to a particular service provider, which the observer could already tell from the IP address. </del> <ins> that private origins will co-locate with or hide behind a provider (CDN, app server, etc.) which is able to activate encrypted SNI (ESNI) for all of the domains it hosts.  Thus, the use of encrypted SNI does not indicate that the client is attempting to reach a private origin, but only that it is going to a particular service provider, which the observer could already tell from the IP address. </ins> 2.

Discussion:
I decided "hidden" was bad. NAME
+1 to the change. I think that this is the right direction.
Change:
the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet been gathered. <del> A direction attribute for the associated RtpTransceiver as described by sec.offer-dirattr. </del> <ins> A direction attribute which is the same as that of the associated transceiver. </ins> For each supported codec, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6.  The audio and video codecs that

Discussion:
Can you separate this from the ICE changes that are also in this PR?
Oops, yeah
NAME PTAL
LGTM
See URL
Change:
The "epoch" field represents the current version of the group key. The "tree_hash" field contains a commitment to the contents of the <del> group's rachet tree and the credentials for the members of the </del> <ins> group's ratchet tree and the credentials for the members of the </ins> group, as described in tree-hashes. The "confirmed_transcript_hash" field contains a running hash over

Discussion:
Yeah, I noticed that too as I was implementing. I will fix it in a “reconciliation with implementation” PR I’m working on.
Here's the Weekly Digest for : - - Last week 4 issues were created. Of these, 0 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by - - Last week, 14 pull requests were created, updated or merged. Last week, 8 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 6 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 10 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 3 contributors. :bustinsilhouette: :bustinsilhouette: :bustinsilhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 11 issues were created. Of these, 1 issues have been closed and 10 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 2 comments.

- - Last week, 11 pull requests were created, updated or merged. Last week, 6 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by Last week, 4 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there were 2 stagazers. :star: :star: You all are the stars! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Change:
Additionally, each code of the format "0x1f * N + 0x21" for integer values of N (that is, "0x21", "0x40", ..., through <del> "0x&#8237;3FFFFFFFFFFFFFFE&#8236;") MUST NOT be assigned by IANA. </del> <ins> "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. </ins> 10.5.

Discussion:
This was fun, it turns out there were actually 3 pair of instances where the were added. I wonder if this was super meta level protest against the endianess-swap from back in the day...
Draft 19 has rendering issue for the reserved frame type in section 10.4
Change:
the certificate for future handshakes based on the CertificateRequest parameters supplied in this handshake.  The server MUST NOT send either of these two options unless it also <del> requested a certificate on this handshake [[OPEN ISSUE: Shoudl we relax this?]] </del> <ins> requested a certificate on this handshake.  [[OPEN ISSUE: Should we relax this?]] </ins> This field is a placeholder for future extensions to the

Discussion:
Consistently capitalize AEAD, fix a missing period, and fix a typo in a comment (for the sole purpose of appeasing my perfectionist tendencies ;).
I don't think changing aead-ciphered to AEAD-ciphered in the protocol description is an improvement. The typo fix is good :)
3 lines below aead-ciphered we have TLSCiphertext. Abbreviations are already kept in caps in almost every place. I don't see why it shouldn't be consistent and do so here as well.
I'd prefer to stay consistent with TLS 1.2.
Meh, ok. It looks out of place to me, but it's not a big deal. Commit revised to just fix the missing period and typo.
Change:
a host which only functions as an ACME server could place the directory under the path "/". <del> If the ACME server does not implement pre-authorization (Section 7.4.1) it MUST omit the "newAuthz" field of the directory. </del> <ins> If the ACME server does not implement pre-authorization (pre- authorization) it MUST omit the "newAuthz" field of the directory. </ins> The object MAY additionally contain a field "meta".  If present, it MUST be a JSON object; each field in the object is an item of

Discussion:
Replaces
This text looks fine to me. I think there should be discussion in WGLC about this since folks that care about pre-authorization might be surprised by this new constraint.
Change:
Load balancers SHOULD drop packets with non-compliant DCIDs in a short header. <ins> Servers that receive packets with noncompliant CIDs MUST use the available mechanisms to induce the client to use a compliant CID in future packets.  In QUIC version 1, this requires using a compliant CID in the Source CID field of server-generated long headers. </ins> A QUIC-LB configuration MAY significantly over-provision the server ID space (i.e., provide far more codepoints than there are servers) to increase the probability that a randomly generated Destination

Discussion:
Make it clear that the server has to provide the client with a compliant DCID if the client isn't already using one.
Dear sir, As you know, there is no bit in the cid to mark whether the cid encoded the server info or not. In this case, no matter the server info encoded or not, the load balancer needs to decrypt or decode the cid. Do you think this is a useless try when the packet is the first initial packet? Do you think this is a useful idea to expand the cid format to use the first bit to mark the cid encoded or not? However, in this case, the client need to obey the rule.
In fact, there is a bit. If the first two bits are '11' that means that the server didn't encode its ID and the load balancer should use 4-tuple routing: URL The very first packet usually has a CID chosen by the client, which knows nothing about QUIC-LB. The beginning of Section 4 is mostly about how load balancers should handle these.
OK, I almost have forgot the first two Config Rotation bits can be used to mark the cid server info's validity. However, in this case, I want to know , for the very first packet, will the draft suggest the clients to generate the dcid with the first two bits "11" , if they know the QUIC-LB used. As, if so, the QUIC-LB know all packets' cid information to prevent useless decode/decrypt try for the very first packet.
No, this draft does not assume client cooperation at all. The very beginning of Section 4 explains how to handle client-generated CIDs.
Thanks for your reply. Actually, I understand your works and Section 4. However, my point is that , even this draft does not assume client cooperation at all, this draft can suggest the client to generate a cid with 11 for the very first initial packet. This is useful for QUIC-LB if client obeys the rule, if not , the Section 4 also works well.
In I'm adding CR bits as a reason for noncompliance. It's fine if the client wants to set '11' , but I don't think it's important to do that. At most all we're saving the LB is a very small decrypt operation.

Even thought the decryption has a low consumption, I insist that the cost can be avoided. I admit that the lb can't assume client cooperation at all, however, the draft can suggest the client to obey the rule: " As, it is impossible for the client to know the server information at the beginning of the QUIC conn, so the DCID in the initial can't encode the server info, in this case, the Client should make the first two bits with "11". "
Change:
(Forbidden) error, with a problem document describing the reason for the rejection. <del> If the authorization request specifies "existing" with a value of "accept" or "require", before proceeding, the server SHOULD determine whether there are any existing, valid authorization resources for the account and given identifier.  If one or more such authorizations exists, a response SHOULD be returned with status code 303 (See Other) and a Location header pointing to the existing resource URL; processing of the request then stops.  If there are multiple such authorizations, the authorization with the latest expiry date SHOULD be returned.  If no existing authorizations were found and the value for "existing" was "require", then the server MUST return status code 404 (Not Found); if it was "accept" or was any other value or was absent, processing continues as follows. </del> If the server is willing to proceed, it builds a pending authorization object from the inputs submitted by the client.

Discussion:
I believe they are unnecessary. The server can set its own policy on whether to give back an existing or a new authz, and the client can choose to accept or reject that. Hugo also pointed out on-list that the status codes for these are inconsistent with the status codes for new-account. If we keep these, we'd want to fix that. But simpler to delete, I think.
Let's Encrypt tell me that they have had a few reports of buggy clients creating enough pending authorizations to saturate their rate limits, so they need a way for clients to clear these out. These clients are also not keeping around authorization URLs, so they can't just go them. My proposed solution would be to re-add the "authorizations" field to the account object, which got lost in the refactor in or so. Together with deactivation, enabling clients to enumerate authorization URLs would solve this problem. You could also envision a more direct solution, offering an endpoint that just deletes all pending authorizations for a client or client+identifier.
This is definitely too specific to these buggy clients. For the flow, the list of orders is sufficient. It's true that technically you can create authorizations through a separate, optional, flow. But Let's Encrypt has no plans to implement that flow, because other CAs have said they cannot / would not implement it, so Let's Encrypt implementing it would split the market. I'm inclined to say let's not complicate the protocol, and hypothetical clients that want to do the flow with some hypothetical server need to keep proper track of their authzs. Also, I think the particular issue with hitting limits for pending authzs can be solved in several ways without modifying the protocol.
If is merged, I would expect that a reasonable ACME server supporting new-authz would return an exiting authz, instead of giving a rate limit error. Or return existing authz from the beginning.
Closing as a result of WG decision at IETF 98
Change:
bandwidth requirements for a router on the delivery path with that number of users downstream.  For example, at a node with 10,000 downstream users simultaneously consuming video streams, <del> approximately up to 80 Gbps would be necessary in order for all of them to get 1080p resolution at 60 fps. </del> <ins> approximately 80 Gbps would be necessary in order for all of them to get typical content at 1080p resolution at 60 fps, or up to 180 Gbps to get sustained high-motion content such as sports, while maintaining the same resolution. </ins> However, when there is some overlap in the feeds being consumed by end users, it is sometimes possible to reduce the bandwidth

Discussion:
This is my attempt at the changes we discussed in URL to include both the high-end and the typical bitrate needs.
Changes look good to me.