jiebi/CodeConvo huggingface dataset:
Change:
Architecture RFC7556 provides some discussion on authenticating an operator. <del> Given that a user chooses to visit a Captive Portal URL, the URL </del> <ins> Given that a user chooses to visit a Captive Portal URI, the URI </ins> location SHOULD be securely provided to the user's device.  E.g., the DHCPv6 AUTH option can sign this information.

Discussion:
This replaces any 'URL' terminology with 'URI'. It also adds an informative reference to RFC 3986 , as suggested. Fixes issue
Multiple reviewers have suggested that we use URI instead of URL. I think we should make this change, and add the informative reference.
Change:
the query domain name.  That is, if a client queries example.com, the ESNI TXT Resource Record might be: <del> Servers SHOULD configure DNS such that, upon querying a domain name with ESNI support, at most one each of A, AAAA, TXT ESNI, and ALTSVC I-D.schwartz-httpbis-dns-alt-svc Resource Record is returned.  Alt- Svc records may be used to inform the client of the plaintext </del> <ins> Servers MUST ensure that, if multiple A, AAAA or ALTSVC I-D.schwartz- httpbis-dns-alt-svc records are returned for a domain with ESNI support, all the servers pointed to by those records are able to handle the keys returned as part of a ESNI TXT record for that domain. Alt-Svc records may be used to inform the client of the plaintext </ins> (fronting) SNI.  If present, clients SHOULD use its value in the SNI extension of the subsequent ClientHello.

Discussion:
See
This looks good to me. Clarifying the requirements rather than specifying how to act makes more sense here. FWIW, I thought the intent of the original text was to encourage not having ESNIKeys shared between multiple hosts whenever possible. This change loses that property. But anyways, that is mentioned in the appendix. Hence my :+1: to the PR.
I suggest dropping the references to Ben's individual alt-svc in DNS draft.. it hasn't been adopted and its future is murky. actual alt-svc (the non dns kind) actually requires the use of the plaintext SNI. As those are both cachable and connections to new IP addresses (less linkable) you could consider updating it with mike bishop's URL (also an individual draft atm)
NAME also suggested that the reference might not be needed in URL so I made to actually remove it.
Regarding: Why is that a SHOULD? Does it apply to both fronting and shared mode? For reference, Cloudflare almost always sends at least two A and AAAA answers for every question. (I get that it's not a MUST, though I'd also like to understand what the reasoning is in the first place)
NAME ??
The idea was to simplify key management. If multiple A or AAAA records are returned, the server needs to ensure each server behind those addresses have all the necessary keys.
NAME I see, I'd rather the spec said that instead of trying to impose limits (I made with suggested fix).
NAME works for me :)
Change:
timeout on UDP NATs might be tempting in light of this property, but not all QUIC server deployments will be robust to rebinding. <del> 4.8.1. </del> <ins> 4.9.1. </ins> NATs sometimes hit an operational limit where they exhaust available public IP addresses and ports, and must evict flows from their

Discussion:
addresses
Should this ID have some mention of ICMP, because support for ICMP with UDP is a known issue for many stacks, and QUIC seems to have thought this through and we can pass that on. So, I think some mention of the use of ICMP would be helpful - at least to refer to the appropriate sections in the QUIC transport spect
I would think this would be handled by the QUIC implementation transparently and therefore it's not in the applicability statement that is directed at application designers who rather use an existing QUIC library. Or what exactly is the advise you would like to see here?
Actually, I was suggesting somewhere just to say something about ICMP because some endpoints didn't traditionally pass ICMP to UDP - this could be manageability rather than applicability?: "QUIC stacks can be designed to receive and safely utilise received ICMP messages when these are provided by the endpoint (e.g to assist PMTUD), but do not rely upon them to function."
Okay, let me think we anything like this belongs. I believe, as you say, manageability might make more sense.
We merged the PR as it seems uncontroversial but I leave the issue open for now, so we don't forget to mention this new section in the meeting.
Change:
The key authorization for this challenge.  This value MUST match the token from the challenge and the client's account key. <del> An IPv4 or IPv6 address, in dotted decimal form or RFC4291 form, respectively.  If given, this address MUST be included in the set of IP addresses to which the domain name resolves when the server attempts validation.  If given, the server SHOULD connect to that specific IP address instead of arbitrarily choosing an IP from the set of A and AAAA records to which the domain name resolves. </del> On receiving a response, the server MUST verify that the key authorization in the response matches the "token" value in the challenge and the client's account key.  If they do not match, then

Discussion:
This reverts commit a5cb357a64ce5e46815544c9faaf94b97b3eba56 I think we did not reach consensus on the list about this feature.
Oh, it's a shame that this was removed. I was hoping to use this feature to help when my servers were behind a load balancer. We should probably remove this reference as well:
Change:
2.3. <ins> NOTE: Despite the name beginning with "ECDH_" (no E), the key used in ECDH_anon is ephemeral just like the key in ECDHE_RSA and ECDHE_ECDSA.  The naming follows the example of DH_anon, where the key is also ephemeral but the name does not reflect it.  TBD: Do we want to rename this so that it makes sense? </ins> In ECDH_anon, the server's Certificate, the CertificateRequest, the client's Certificate, and the CertificateVerify messages MUST NOT be sent.

Discussion:
Added new curves and new authors. Partial merge of draft-ietf-tls-curve25519
Change:
The attacker modifies my HTTP connection to inject an IFRAME (or a redirect) to http://calling-service.example.com <del> The attacker forges the response apparently http://calling- </del> <ins> The attacker forges the response apparently from http://calling- </ins> service.example.com/ to inject JS to initiate a call to himself. Note that this attack does not depend on the media being insecure.

Discussion:
Addressing Alissa's comments. I also added to periods that I noticed were missing.
NAME NAME PTAL
Scratch that, I'm reading backwards. The references are fine.
Change:
computed as described in public-issuer-configuration. Challenge value "challenge", an opaque byte string.  For example, <del> this might be provided by the redemption protocol in HTTP- Authentication. </del> <ins> this might be provided by the redemption protocol in AUTHSCHEME. </ins> Given this configuration and these inputs, the two messages exchanged in this protocol are described below.

Discussion:
There's and . I'm guessing these should be collapsed to just one.
table 2 says: -- | -- and Section 8.1 says: What is the Token Type registry and what are the constraints on values in the registry? It's implied that values should be integers but JSON numbers are quite flexible, so would it be valid for me to register e.g. a negative integer. If the "Token Type" registry already exists, I'm not able to find it and a link would be useful. If it doesn't exist and this document wishes to create it, then more work is needed to establish that registry and it's procedures.
We're missing a link to the HTTP auth document, where the registry is defined. Good catch!
Change:
4. <del> ECH uses draft-07 of HPKE for public key encryption I-D.irtf-cfrg- </del> <ins> ECH uses draft-08 of HPKE for public key encryption I-D.irtf-cfrg- </ins> hpke.  The ECH configuration is defined by the following "ECHConfig" structure.

Discussion:
and also updates the ECH version. I didn't bump the extension codepoint for "echisinner," since that seems harmless. cc NAME NAME
This new version of the draft removes the version-vector dependency, so this should be the last time we update the pinned version.
Works for me!
Change:
The transport services API resolves names internally, when the Initiate(), Listen(), or Rendezvous() method is called to establish a <del> Connection.  The API explicitly does not require the application to resolve names, though there is a tradeoff between early and late binding of addresses to names.  Early binding allows the API implementation to reduce connection setup latency, at the cost of potentially limited scope for alternate path discovery during Connection establishment, as well as potential additional information leakage about application interest when used with a resolution method (such as DNS without TLS) which does not protect query confidentiality. </del> <ins> Connection.  Privacy considerations for the timing of this resolution are given in privacy-security. </ins> The Resolve() action on Preconnection can be used by the application to force early binding when required, for example with some Network

Discussion:
I would reword this text in §5.1: such that the tradeoff is listed in a (new) privacy considerations section, leaving the description of the reduced connection setup latency in early binding here as a functional justification.
LGTM (note: accept 1 nit fix before pressing Merge)
Change:
HTTP/3 can either rely on transport-layer padding or employ the reserved frame and stream types discussed in frame-reserved and stream-grease.  These methods of padding produce different results in <del> terms of the granularity of padding, the effect of packet loss and recovery, and how an implementation might control padding. </del> <ins> terms of the granularity of padding, how padding is arranged in relation to the information that is being protected, whether padding is applied in the case of packet loss, and how an implementation might control padding. </ins> 10.2.

Discussion:
This text was pretty good and more or less covered the problem already, but I think that this might be slightly better. NAME if you don't like this, close this AND .
From a discussion on : We should probably have a conversation about the trade-offs with padding. Transport-layer padding is in some ways superior, like in how it can be granular to a single byte, which reserved streams and frames cannot do. But PADDING frames at the transport aren't retransmitted when lost, which could lead to some interesting attacks if packets can be suppressed by an attacker. If retransmissions aren't padded, boom. Originally posted by NAME in URL
Change:
11. <del> Multi-path QUIC transport error codes are 62-bit unsigned integers </del> <ins> Multipath QUIC transport error codes are 62-bit unsigned integers </ins> following QUIC-TRANSPORT. This section lists the defined multipath QUIC transport error codes

Discussion:
Be consistent with title.
NAME flagged in his PRs that there are many places using hyphenated "multi-path" and many using "multipath". We need to fix that.
This is due to the merge of the different drafts. I thought I fixed most of them, but I guess I could have done a search :-) Will do
Change:
Be Visible to the Enforcement Device <ins> An identifier might only apply to the current point of network attachment.  If the device moves to a different network location its identity could change. </ins> 3.2.1. In order to uniquely identify the User Equipment, at most one user

Discussion:
Fixes Issue
NAME Thanks for the quick review.
The information needs to only apply to the current point of network attachment. That is obvious, perhaps, but worth stating. Thanks to Warren Kumari.
NAME Can you take a look at PR ? I want to make sure I've captured Warren's point properly.
I think that's about right. But you should avoid 2119 language. I have a few suggestions (if only GitHub had multi-line suggestions...).
Change:
A server might receive a packet addressed to its preferred IP address at any time after it accepts a connection.  If this packet contains a PATH_CHALLENGE frame, the server sends a PATH_RESPONSE frame as per <del> migrate-validate.  The server MAY send other non-probing frames from its preferred address, but MUST continue sending all probing packets from its original IP address. </del> <ins> migrate-validate.  The server MUST send other non-probing frames from its original address until it receives a non-probing packet from the client at its preferred address and until the server has validated the new path. </ins> <del> The server SHOULD also initiate path validation of the client using its preferred address and the address from which it received the client probe.  This helps to guard against spurious migration </del> <ins> The server MUST probe on the path toward the client from its preferred address.  This helps to guard against spurious migration </ins> initiated by an attacker. Once the server has completed its path validation and has received a

Discussion:
Editorial because it now says what we originally thought it said, but design because it is changing normative language. Does not interact with .
The following text is kind of hard to track: I'm not really following what's going on here. The server knows that it has two addresses and it wants to use its preferred address. Why does it have to probe from its preferred address. Also, I don't understand how these two paragraphs work together. The first one says you have to send probing packets from your original address but the second paragraph tells you to probe from the preferrd address.
You're right, that last restriction in the first paragraph looks backwards. IIRC, it's supposed to be a reiteration of the fact that the client decides when to actually cut over, so the server shouldn't be sending non-probing packets from the preferred address until the client starts sending them there. This is section 9.6.2 of Transport.
I think that the first paragraph is just missing "... until it receives a non-probing packet from the client at its preferred address." Then maybe a simple: "The server MUST probe on the path toward its preferred address before sending non-probing packets."
Change:
While hashes at the nodes are used to check the integrity of the subtrees, signatures are required to provide authentication and group <del> agreement.  Siganatures are especially important in the case of </del> <ins> agreement.  Signatures are especially important in the case of </ins> newcomers and MUST be verified when joining.  All nodes in the tree MUST be signed to provide authentication and group agreement.

Discussion:
These are resolved in .
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 3 comments. - - Last week, 8 pull requests were created, updated or merged. Last week, 7 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 3 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :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 .
Change:
specific PvD instances or interface instances, and should be preferred over these options. <ins> The default is to not set a preference for any PvD. </ins> 5.2.12. local-address-preference

Discussion:
Added defaults for interface and PvD following . Also, I caught one leftover "recommended default".
We require implementations to have default but we don't provide any recommendation for interface and PvD.
For Interface, this would the default be to set "Ignore" on all available interfaces, right? This indicates that the application has no preferences of its own, so the implementation can apply some default system policy. Also, if the application specified some local endpoint, this might constrain the actual interfaces used (related to ). If we try to phrase this as (Preference, Enumeration), it reads a bit weird though: ("Ignore", "Cellular") and ("Ignore", "WiFi"), for example. So perhaps we should just write text saying that the default is to set no application preference.
I think text is fine as well but we need to say something.
Thanks!
Change:
uncompressed Certificate message and to enforce limits on the message size before performing decompression. <del> The compressed body of the Certificate message, in the same format as it would normally be expressed in.  The compression algorithm </del> <ins> The result of applying the indicated compression algorithm to the encoded Certificate message that would have been sent if certificate compression was not in use.  The compression algorithm </ins> defines how the bytes in the compressed_certificate_message field are converted into the Certificate message.

Discussion:
Update reference.
Almost, but I think I can accept my own suggestions so I'll just do that and merge.
Change:
registration with an RD.  To use the interface, the endpoint sends a POST request to the registration resource returned in the Location header option in the response returned from the intial registration <del> operation. </del> <ins> operation.  The POST request (in contrats to PUT) allows replacing selection of a resource. </ins> An update MAY update the lifetime or context registration parameters "lt", "con" as in registration ) if the previous settings are to be

Discussion:
atomicity idempotency, Jim multiple query parameter, Fairhair deleted eps from group, Jim simple registration, hauke
Change:
3. <del> This document defines a new extension type (connection_id(TBD)), which is used in ClientHello and ServerHello messages. </del> <ins> This document defines the "connection_id" extension, which is used in ClientHello and ServerHello messages. </ins> The extension type is specified as follows.

Discussion:
It probably makes sense to be a little more consistent.
Makes sense. I will do this after the current wave of pull requests have been reviewed and accepted/rejected.
I addressed this issue in PR
Addressed with submitted draft version -04
I don't think that you need to change the grammar.
Change:
The three high bits of the first byte of the DTLSCiphertext header are set to 001.  This ensures that the value will fit within the DTLS region when multiplexing is performed as described in <del> RFC7983. </del> <ins> RFC7983.  It also ensures that distinguishing encrypted DTLS 1.3 records from encrypted DTLS 1.2 records is possible when they are carried on the same host/port quartet; such multiplexing is only possible when connection IDs I-D.ietf-tls-dtls-connection-id are in use, in which case DTLS 1.2 records will have the content type tls12_cid (25). </ins> The C bit (0x10) is set if the Connection ID is present.

Discussion:
…
I don't.
It would also be good to add a note on how we tell the difference between DTLS 1.2 and 1.3. Version information is carried in various places and due to the use of the CID the multiplexing got more complex between 1.2 and 1.3.
This WFM
Change:
correct delivery will not be trusted regarding the group membership information either. <del> 2.3.3. </del> <ins> 2.2.3. </ins> A particularly important security constraint in that an adversary must not be able to gain access to information about the identity of

Discussion:
A few minor edits to (hopefully) improve readability, and a few comments in square braces ([ ]).
Something looks wrong with your text editor... ;)
Arg! Will fix, sorry about this.
Change:
6.3. <del> At some points in the protocol, it is necessary for the server to determine whether two JSON Web Key (JWK) RFC7517 objects represent the same key.  In performing these checks, the server MUST consider two JWKs to match if and only if they have the identical values in all fields included in the computation of a JWK thumbprint for that key.  That is, the keys must have the same "kty" value and contain identical values in the fields used in the computation of a JWK thumbprint for that key type: "RSA": "n", "e" "EC": "crv", "x", "y" Note that this comparison is equivalent to computing the JWK thumbprints of the two keys and comparing thumbprints.  The only difference is that there is no requirement for a hash computation (and thus it is independent of the choice of hash function) and no risk of hash collision. 6.4. </del> It is common in deployment for the entity terminating TLS for HTTPS to be different from the entity operating the logical HTTPS server, with a "request routing" layer in the middle.  For example, an ACME

Discussion:
Instead of defining a whole new key equivalence method just check the JWK verifies the inner JWS.
Change:
Zero padding whose length makes the serialized PaddedServerNameList struct have a length equal to <del> ESNIConfig.padded_length. </del> <ins> ESNIConfigContents.padded_length. </ins> This value consists of the serialized ServerNameList from the "server_name" extension, padded with enough zeroes to make the total <del> structure ESNIConfig.padded_length bytes long.  The purpose of the padding is to prevent attackers from using the length of the </del> <ins> structure ESNIConfigContents.padded_length bytes long.  The purpose of the padding is to prevent attackers from using the length of the </ins> "encrypted_server_name" extension to determine the true SNI.  If the <del> serialized ServerNameList is longer than ESNIConfig.padded_length, the client MUST NOT use the "encrypted_server_name" extension. </del> <ins> serialized ServerNameList is longer than ESNIConfigContents.padded_length, the client MUST NOT use the "encrypted_server_name" extension. </ins> The ClientEncryptedSNI.encrypted_sni value is then computed using AEAD-Encrypt (RFC5116; Section 2.1) with the AEAD corresponding to

Discussion:
ESNIConfig has a version number in front for extensibility, but it is unclear what the version invariants are. Presumably we would like versions to change the contents of an ESNIConfig (indeed different drafts have done so), but it is not obvious this is possible and it is impossible to skip over an ESNIConfig with a version you do not understand. Fix this by moving the body of an ESNIConfig into an ESNIConfigContents and adding a length prefix in front.
As of draft-ietf-tls-esni-04, when the server rejects ESNI with esniretryrequest, it includes one or more ESNIKeys for retry: The client behavior described in section 5.1.2 is to pick one of the ESNIKeys values from this vector: Encoding of contains the total size of the vector field but not the size of the individual ESNIKeys elements. This makes it difficult (impossible?) to parse a vector with unknown future versions, so this part is not really extensible.
Thanks for the comment! URL should resolve this. It's a little goofy-looking but ah well.
Thank you for confirming the issue. Not the nicest but will be effective. It's the only real blocking point I see when implementing draft -04.