jiebi/CodeConvo huggingface dataset:
Change:
changing any of their contents. Let the group of peers who know the key be "A", "B", and "C".  The <del> attack proceeds as follows: 1.  "A" sends a "ClientHello" to "B" 2. The attacker intercepts the message and redirects it to "C" 3.  "C" responds with to "A" 4.  "A" sends a "Finished" message to "B" "A" has completed the handshake, ostensibly with "B".  5.  The attacker redirects the "Finished" message to "C" "C" has completed the handshake, ostensibly with "A". </del> <ins> attack proceeds as follows: "A" sends a "ClientHello" to "B". The attacker intercepts the message and redirects it to "C". "C" responds with to "A". "A" sends a "Finished" message to "B".  "A" has completed the handshake, ostensibly with "B". The attacker redirects the "Finished" message to "C".  "C" has completed the handshake, ostensibly with "A". </ins> This attack violates the peer authentication property, and if "C" supports a weaker set of cipher suites than "B", this attack also

Discussion:
Addresses , , and .
... and don’t prohibit or otherwise interfere with PAKEs. (Though we may want to state that PAKEs should produce PSKs that adhere to this limit if run out of band.)
Fixed in .
Fixed in .
Start with the general recommendation and invariant: Identities should be unique across all nodes, roles, and keys. For each use case, how a part of the invariant is violated and leads to one of the known attacks.
Fixed in .
Change:
5. <ins> If, given an authenticator request, the endpoint does have an appropriate certificate or does not want to return one, it constructs an authenticated refusal called an empty authenticator.  This is an HMAC over the hashed authenticator transcript with a Certificate message containing no CertificateEntries and the CertificateVerify message omitted: "Hash(Handshake Context || authenticator request || Certificate) " The HMAC is computed using the same hash function using the Finished MAC Key as a key. 6. </ins> The creation and validation of both authenticator requests and authenticators SHOULD be implemented inside the TLS library even if it is possible to implement it at the application layer.  TLS

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:
11.3. This document will request IANA to add the following values to the <del> "HTTP Capsule Types" registry created by HTTP-DGRAM: </del> <ins> "HTTP Capsule Types" registry maintained at <<https://www.iana.org/assignments/http-capsule-protocol/http- capsule-protocol.xhtml>>. </ins>

Discussion:
There should be a reference providing an URL for the Assigned Internet Protocol Number registry in this document, not just the name, even if this is formally sufficient. The URL is: URL
Change:
be presented over the TLS channel in question with the same level of trust.  The verifier is responsible for ensuring the key in the TLS client certificate is the one expected for a particular request.  For <del> example, if the request is a grant request [40], the AS needs to compare the TLS client certificate presented at the TLS layer to the key identified in the request body itself (either by value or through a referenced identifier). </del> <ins> example, if the request is a request, the AS needs to compare the TLS client certificate presented at the TLS layer to the key identified in the request body itself (either by value or through a referenced identifier). </ins> Furthermore, the prevalence of the TLS-terminating reverse proxy (TTRP) pattern in deployments adds a wrinkle to the situation.  In

Discussion:
fixed some typos fixed a broken reference HTTP -> HTTP to keep it consistent not sure if it is actually supposed to be "Key-Bound Token Access Tokens"
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 5faf7b6b37c82891ee35bd06e0a71419b2fbeddc Inspect the deploy log: Browse the preview:
Change:
This document describes how to proxy UDP over HTTP.  Similar to how the CONNECT method allows proxying TCP over HTTP, this document <del> defines a new mechanism to proxy UDP.  It is built using HTTP Extended CONNECT. </del> <ins> defines a new mechanism to proxy UDP.  When using HTTP/2 or HTTP/3, it uses Extended CONNECT; when using HTTP/1.1, it uses Upgrade. </ins> 1.

Discussion:
That omits the HTTP/1.1 support that you have. Is that intentional?
You're right that should be fixed - the intro is correct but the abstract needs to be updated to look more like the corresponding text in the into
Change:
1.1. <del> A full review of all streaming media considerations is too wide a </del> <ins> A full review of all streaming media considerations is too broad a </ins> topic to cover comprehensively in a single document. This document focuses chiefly on large-scale delivery of streaming

Discussion:
Check against new main version for duplication on scope.
Discussion from editor's conference call: find a better place to put description of WebRTC (now that we have a good scope section).
From NAME
NAME - please see what you think of the new location for the mention of WebRTC.
Sure, this seems fine.
Change:
Client, the Issuer completes the issuance flow by computing a blinded response as follows: <del> This is encoded and transmitted to the client in the following </del> <ins> The BlindSign function is defined in Section 4.3 of BLINDRSA.  The result is encoded and transmitted to the client in the following </ins> TokenResponse structure: <del> The rsabssa_blind_sign function is defined in BLINDRSA, Section 5.1.2..  The Issuer generates an HTTP response with status code 200 whose content consists of TokenResponse, with the content type set as "application/private-token-response". </del> <ins> The Issuer generates an HTTP response with status code 200 whose content consists of TokenResponse, with the content type set as "application/private-token-response". </ins> 6.3. Upon receipt, the Client handles the response and, if successful, processes the content as follows: <del> The rsabssa_finalize function is defined in BLINDRSA, Section 5.1.3.. If this succeeds, the Client then constructs a Token as described in </del> <ins> The Finalize function is defined in Section 4.4 of BLINDRSA.  If this succeeds, the Client then constructs a Token as described in </ins> AUTHSCHEME as follows: The Token.nonce value is that which was sampled in private-request. <del> If the rsabssa_finalize function fails, the Client aborts the protocol. </del> <ins> If the Finalize function fails, the Client aborts the protocol. </ins> 6.4.

Discussion:
This link is broken in a few ways. Note that the links has an trailing period in it, which is only part of the problem there; there is no Section 5.1.2 or Section "5.1.2.". Also, the function is called "BlindSign" in that version of the draft.
In the issuance protocol draft, there are a few places where it is assumed that a value will be a certain length, but no effort has been made to explicitly set a length. In : Is the 0x0002 two octets? Sure, you might readily assume that, but nothing says that explicitly. The same assumption appears in Sections 5.1 and 5.5.
Change:
UDP connections represent a pair of specific IP addresses and ports on two hosts. <del> Calling "Initiate" on a UDP Connection causes it to reserve a local port, but does not generate any traffic. </del> <ins> CONNECT.UDP.  Calling "Initiate" on a UDP Connection causes it to reserve a local port, but does not generate any traffic. </ins> Early data on a UDP Connection does not have any special meaning. The data is sent whenever the Connection is Ready.

Discussion:
(SCTP mapping) This uses a new approach for such text for TCP, UDP and SCTP. Also: updates appendix D of interface.
We've updated Implementation mapping details for most protocols with , but we didn't tackle SCTP yet.
I'm fine with this being assigned to me. However, it's more than just writing the SCTP text. Here's the relevant part of what I wrote in PR : I don't suggest to delete much of the text that's there but definitely amend it with the RFC reference at least for what's covered in RFC 8303. There's a very direct line from this type of text in RFC 8303 to the original specs, so I do believe that should be helpful. That's (obviously) post-Montreal though!
NAME please send a PR along these lines.
Change:
zero.  Whether or not it implements this method, the server MUST NOT reuse a nonce until it switches to a configuration with new keys. <del> Configuration agents SHOULD implement an out-of-band method to discover when servers are in danger of exhausting their nonce space, and SHOULD respond by issuing a new configuration.  A server that has exhausted its nonces MUST either switch to a different configuration, or if none exists, use the 4-tuple routing config rotation codepoint. </del> <ins> Both the Plaintext CID and Block Cipher CID algorithms send parts of their nonce in plaintext.  Servers MUST generate nonces so that the plaintext portion appears to be random.  Observable correlations between plaintext nonces would provide trivial linkability between individual connections, rather than just to a common server. For any algorithm, configuration agents SHOULD implement an out-of- band method to discover when servers are in danger of exhausting their nonce space, and SHOULD respond by issuing a new configuration. A server that has exhausted its nonces MUST either switch to a different configuration, or if none exists, use the 4-tuple routing config rotation codepoint. When sizing a nonce that is to be randomly generated, the configuration agent SHOULD consider that a server generating a N-bit nonce will create a duplicate about every 2^(N/2) attempts, and therefore compare the expected rate at which servers will generate CIDs with the lifetime of a configuration. </ins> 11.7.

Discussion:
the server no longer has discretion to lengthen the CID. Also, the algorithms are more aligned so there has to be less unique text associated with each algorithm.
In any given deployment, the server use length should be consistent. The load balancer doesn't strictly need to know what it is, but obviously not doing this will lead to observable correlations.
As we've generalized the concept of a nonce, we should abolish the concept of "server use" and make it all a nonce. If the servers need to use the same length to prevent linkability, best to make it part of the configuration.
Change:
QPACK defines two settings which are included in the HTTP/3 SETTINGS frame. <del> An integer with a maximum value of 2^30 - 1.  The default value is zero bytes.  See _table-dynamic for usage.  This is the equivalent of the SETTINGS_HEADER_TABLE_SIZE from HTTP/2. </del> <ins> The default value is zero.  See _table-dynamic for usage.  This is the equivalent of the SETTINGS_HEADER_TABLE_SIZE from HTTP/2. </ins> <del> An integer with a maximum value of 2^16 - 1.  The default value is zero.  See overview-hol-avoidance. </del> <ins> The default value is zero.  See overview-hol-avoidance. </ins> 6.

Discussion:
In addition, remove verbiage stating that the settings values are integers, as the are integers by the definition of the SETTINGS frame.
Both specify the maximum value the decoder supports. The encoder is free to pick and use a smaller value. There is no reason to add artificial limits to the way an decoder is implemented.
This could be viewed as an alternative resolution to .
Also, historical note: These have maxima because settings used to be length-prefixed blobs. By defining them to be integers of a maximum size, the length could be constrained. Now that we use varints, there is a maximum structural size already.
Change:
"ExtensionType Values" registry, defined in RFC5246, for connection_id(TBD) defined in this document. <del> IANA is requested to allocate the following new values in the "TLS ContentType Registry": alert_with_cid(25) handshake_with_cid(26) application_data_with_cid(27) heartbeat_with_cid(28) </del> <ins> IANA is requested to allocate tls12_cid(25) in the "TLS ContentType Registry". </ins>

Discussion:
URL Still contains the content types removed in PR . alertwithcid(25) handshakewithcid(26) applicationdatawithcid(27) heartbeatwithcid(28) I guess, it should be updated towards PR ? tls12cid(25)
The PR can be found here: URL
The PR will fix it.
Change:
Transport Services architecture.  The Transport Services Application Programming Interface (API) is based on an asynchronous, event-driven interaction pattern.  It uses messages for representing data transfer <del> to applications, and it assumes an implementation that can use </del> <ins> to applications, and it describes how implementations can use </ins> multiple IP addresses, multiple protocols, and multiple paths, and provide multiple application streams.  This document further defines common terminology and concepts to be used in definitions of

Discussion:
Address
I think the word /assumes/ is not a good choice of word in the arch draft. OLD: and it assumes an implementation that can use multiple IP addresses, multiple protocols, multiple paths, and provide multiple application streams NEW: and it can provide benefit when an implementation can use multiple IP addresses, multiple protocols, multiple paths, and provide multiple application streams.
Done
Exactly what I expected to see!
Change:
connection from that endpoint.  This corresponds, for example, to a TCP simultaneous open RFC0793.  The process of identifying options for the connection, such as resolution of the Remote <del> Endpoint, occurs during the Rendezvous call.  If successful, the rendezvous call returns a Connection object to represent the established peer-to-peer connection. </del> <ins> Endpoint, occurs during the Rendezvous call.  As with Listeners, the set of local paths and endpoints is contrained by Selection Properties.  If successful, the Rendezvous call returns a Connection object to represent the established peer-to-peer connection. </ins> 4.1.4.

Discussion:
Address
meh okay if we must. :P nah this is great, already merged it.Fine - works
Change:
The "index-selector" applied with a "quoted-member-name" to an object selects the node of the corresponding member value from it, if and <del> only if that object has a member with that name.  The behaviour is unpredictable if the object has duplicate names.  Nothing is selected </del> <ins> only if that object has a member with that name.  Nothing is selected </ins> from a value that is not a object. The "index-selector" applied with an "element-index" to an array

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
Change:
Importance: Extra <del> When we drop a UDP-level datagram.  This is typically if it does not contain a valid QUIC packet (in that case, use packet_dropped instead). </del> <ins> When a UDP-level datagram is dropped.  This is typically done if it does not contain a valid QUIC packet (in that case, use packet_dropped instead). </ins> Definition:

Discussion:
Work towards resolving , for the QUIC events document.
This is great. There are 2-3 instances in the h3 document as well that could use similar re-wording. I'll post a PR for that
Change:
The three ECN Counts are: A variable-length integer representing the total number of packets <del> received with the ECT(0) codepoint. </del> <ins> received with the ECT(0) codepoint in the packet number space of the ACK frame. </ins> A variable-length integer representing the total number of packets <del> received with the ECT(1) codepoint. </del> <ins> received with the ECT(1) codepoint in the packet number space of the ACK frame. </ins> A variable-length integer representing the total number of packets <del> received with the CE codepoint. </del> <ins> received with the CE codepoint in the packet number space of the ACK frame. </ins> ECN counts are maintained separately for each packet number space.

Discussion:
Specify that ECN counts in the ACK frame to be in the same pn_space of the ACK frame. Change pseudocode in recovery-draft to reflect that.
This only changes pseudocode and no normative text, so I'm inclined to mark it editorial and merge it.
Are ECN counts in ACK frames per pnspace or unified across pnspaces? I've observed different behaviors of public servers regarding that. [13.3.1. ECN Counts] seems to suggest they are per pnspace: However, [19.3.2. ECN Counts] says: Pseudocode in the recovery draft (Appendix B. Congestion Control Pseudocode) also has a global ecnce_counter.
Thanks for the issue, NAME PR looks good.
Thanks! NAME want to take a look?
Change:
6. <ins> [[RFC editor: please remove this section before publication.]] WebTransport over HTTP/3 uses two different mechanisms to negotiate versions for the different parts of the draft. The hop-by-hop wire format aspects of the protocol are negotiated by changing the codepoint used for the SETTINGS_ENABLE_WEBTRANSPORT parameter.  Because of that, any WebTransport endpoint MUST wait for the peer's SETTINGS frame before sending or processing any WebTransport traffic.  When multiple versions are supported by both of the peers, the most recent version supported by both is selected. The data exchanged over the CONNECT stream is transmitted across intermediaries, and thus cannot be versioned using a SETTINGS parameter.  To indicate support for different versions of the protocol defined in this draft, the clients SHALL send a header for each version of the draft supported.  The header corresponding to the version described in this draft is "Sec-Webtransport-Http3-Draft02"; its value SHALL be "1".  The server SHALL reply with a "Sec- Webtransport-Http3-Draft" header indicating the selected version; its value SHALL be "draft02" for the version described in this draft. 7. </ins> WebTransport over HTTP/3 satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a secure framework for client-server communication in cases when the

Discussion:
This change both describes the existing mechanism (SETTINGS). It also adds a header in the unlikely scenario that we would need to change capsule stream format (instead of just defining new capsules).
Change:
least some of the time.  However they would like to use an encrypted DNS protocol rather than Do53. <del> Using an encrypted and authenticated resolver that is equivalent to the one provisioned by the network can provide several benefits that are not possible if only unencrypted DNS is used: </del> <ins> Using an encrypted and authenticated resolver can provide several benefits that are not possible if only unencrypted DNS is used: </ins> Prevent other devices on the network from observing client DNS messages

Discussion:
This PR simplifies further by removing any mention of properties of the encrypted resolvers, or properties of the relationship between the Do53 and the encrypted resolver. It now purely focusses on the ability of an untrusted network or resolver to designate other encrypted resolvers. This is an assertion that the encrypted resolver is safe and appropriate to use, but little else. Clients will of course make their own decisions about whether to use designated resolvers or not. Other drafts will look at trusted networks, and communicating information that can be useful to clients as part of the untrusted decision-making.
comments
comments on the draft02
It was pointed out that this should be limited to IETF-standardised encrypted DNS protocols rather than potentially including DNSCrypt and being very open-ended.
Change:
key that can be used to encrypt to that client, and which other clients can use to introduce the client to a new group. <ins> An object that summarizes the state of the group.  The group context is signed to bind a message to a particular group, and also provided to new members to help them join a group. </ins> A signing key pair used to authenticate the sender of a message. An MLSPlaintext or MLSCiphertext message carrying an MLS Proposal

Discussion:
There are several references to GroupContext in the first few sections. The details are fine where they are, but it would be good to introduce the notion that GroupContext summarizes the state of the group.
Change:
DetNet PW by a PE before it is output on the Attachment Circuit(s) (AC). <del> TSN specific function(s) of Edge Nodes (T-PE) are belonging to the native service processing (NSP) RFC3985 block.  This is similar to other functionalities being defined by standard bodies other than the IETF (for example in case of Ethernet: stripping, overwriting or adding VLAN tags, etc.).  Depending on the TSN role of the Edge Node in the end-to-end TSN service selected TSN functions must be supported. </del> <ins> TSN packet processing function(s) of Edge Nodes (T-PE) are belonging to the native service processing (NSP) RFC3985 block.  This is similar to other functionalities being defined by standard bodies other than the IETF (for example in case of Ethernet: stripping, overwriting or adding VLAN tags, etc.).  Depending on the TSN role of the Edge Node in the end-to-end TSN service selected TSN functions are supported. </ins> When a PE receives a packet from a CE, on a given AC with DetNet <del> service, it MUST first check via Stream Identification whether the packet belongs to a configured TSN Stream (i.e., App-flow from DetNet perspective).  If no Stream ID is matched and no other (VPN) service is configured for the AC then packet MUST be dropped.  If there is a matching TSN Stream then the Stream-ID specific TSN functions MUST be executed (e.g., ingress policing, header field manipulation in case of active Stream Identification, FRER, etc.).  Source MAC lookup MAY also be used for local MAC address learning. </del> <ins> service, it MUST first check via Stream Identification (see Clause 6. of IEEE8021CB and IEEEP8021CBdb) whether the packet belongs to a configured TSN Stream (i.e., App-flow from DetNet perspective).  If no Stream ID is matched and no other (VPN) service is configured for the AC then packet MUST be dropped.  If there is a matching TSN Stream then the Stream-ID specific TSN functions MUST be executed (e.g., ingress policing, header field manipulation in case of active Stream Identification, FRER, etc.).  Source MAC lookup MAY also be used for local MAC address learning. </ins> If the PE decides to forward the packet, the packet MUST be forwarded according to the TSN Stream specific configuration to connected CE(s)

Discussion:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)
Change:
expiration increases resilience to packet drops, thus reducing the probability of consecutive PTO events. <del> Probe packets sent on a PTO MUST be ack-eliciting.  A probe packet SHOULD carry new data when possible.  A probe packet MAY carry retransmitted unacknowledged data when new data is unavailable, when flow control does not permit new data to be sent, or to opportunistically reduce loss recovery delay.  Implementations MAY use alternative strategies for determining the content of probe packets, including sending new or retransmitted data based on the application's priorities. </del> When the PTO timer expires multiple times and new data cannot be sent, implementations must choose between sending the same payload every time or sending different payloads.  Sending the same payload

Discussion:
When writing , I found some of the text organization to be odd, so this moves it some.