jiebi/CodeConvo huggingface dataset:
Change:
are relevant or explicitly accept that the original address might change. <ins> 10.11. Several characteristics of HTTP/3 provide an observer an opportunity to correlate actions of a single client or server over time.  These include the value of settings, the timing of reactions to stimulus, and the handling of any features that are controlled by settings. As far as these create observable differences in behavior, they could be used as a basis for fingerprinting a specific client. HTTP/3's preference for using a single QUIC connection allows correlation of a user's activity on a site.  Reusing connections for different origins allows for correlation of activity across those origins. Several features of QUIC solicit immediate responses and can be used by an endpoint to measure latency to their peer; this might have privacy implications in certain scenarios. </ins> 11. This document registers a new ALPN protocol ID (iana-alpn) and

Discussion:
The follow-on to ; depends on . DO NOT MERGE before lands. Imports most of the HTTP/2 Security Considerations text, modulo updates to reference HTTP/3 or http-core concepts. Suggestions on a more sensible structuring of concerns welcome; this still feels like a bit of a grab-bag.
There's a few places where it seems the new "field" terminology is applied inconsistently, but given the PR dependency chain maybe that will shake out. I'll take another look once other things have landed.
Given the chain, this PR should consistently use the new terminology. If I missed something, please flag it.
HTTP-core is making some terminology changes that HTTP/3 should track: In URL, "non-final" responses are "interim" responses In URL, terminology around header, field, value is changing Related to , but this is more than just pointing at the new documents.
NAME these comments/suggestion address my earlier one about use of headers. I might be applying things wrong.Looks good to me. Thanks for doing the hard work here.
Change:
Local hardware cryptographic offload devices may accelerate QUIC servers by receiving keys from the QUIC implementation indexed to the connection ID.  However, on physical devices operating multiple QUIC <del> servers, it is impractical to efficiently lookup these keys if the connection ID does not self-encode its own length. </del> <ins> servers, it might be impractical to efficiently lookup keys if the connection ID varies in length and does not self-encode its own length. </ins> Note that this is a function of particular server devices and is irrelevant to load balancers.  As such, load balancers MAY omit this

Discussion:
This only applies if the CID varies in length (so say that). Also, it only applies if the common stem doesn't otherwise distinguish itself enough to allow an efficient lookup (so say "might" rather than get into all that). In other words, it's probably inefficient, but not necessarily so.
Change:
flow control limits set by its peer, and continues to accept and process MAX_STREAM_DATA frames.  An endpoint in the "Send" state generates STREAM_DATA_BLOCKED frames if it is blocked from sending by <del> stream or connection flow control limits data-flow-control. </del> <ins> stream flow control limits data-flow-control. </ins> After the application indicates that all stream data has been sent and a STREAM frame containing the FIN bit is sent, the sending part

Discussion:
This should address all of them at once; one per commit for those that I think need action. This is probably OK: This is not expressly forbidden. We do say : Which doesn't really contradict the other. FWIW, I'm not a fan of allowing frames to be copied, implementations really should do that, but it's a consequence of having frame idempotency. This is one I'm not sure about: What is the prevailing advice regarding MTU and tunnels? Clearly when you tunnel you get a smaller MTU, but I haven't seen what happens when IPv6 is tunneled over a network that has a minimum MTU. Most paths don't have that small an MTU, so it might be that things just fail.
I realized that there are some answers here in the description, but probably best to move them to the relevant issues anyways.
NAME said: >
NAME said: with TLS.
NAME said:
NAME said: this true for PATH_CHALLENGE? I thought this quite explicitly shouldn't be copied.
My recommendation is to answer the question, but not change anything. See for an answer.
Very well, please close this issue. Sorry for the confusion.
NAME said: RESET_RECVD.
NAME said:
NAME said:
This looks good to me, with NAME 's nit.
Change:
5. <ins> By removing or reducing the need for captive portals to perform MITM hijacking, this mechanism improves security by making the portal and its actions visible, rather than hidden, and reduces the likelihood that users will disable useful security safeguards like DNSSEC validation, VPNs, etc.  In addition, because the system knows that it is behind a captive portal, it can know not to send cookies, credentials, etc.  By handing out a URI which is protected with TLS, the captive portal operator can attempt to reassure the user that the captive portal is not malicious. </ins> An attacker with the ability to inject DHCP messages or RAs could include an option from this document to force users to contact an address of his choosing.  As an attacker with this capability could

Discussion:
""" — Section 5 — Purely a judgment thing here, so do what you hink is best: it seems to me that the Security Considerations in 7710 rather buried the lede. The bottom line is that by removing the MitM interception, this mechanism improves security by making the portal and its actions visible, rather than hidden, and that vulnerabilities that exist here also existed before and are now lessened. I would say something like that up front, in a new first paragraph, and then continue with the existing text as is. But, again, as you judge best; this is just a comment. """
Change:
The need for the term "fully qualified domain name" comes from the existence of partially qualified domain names, which are names where one or more of the earliest labels in the ordered list are <del> omitted (for example, "www").  Such relative names are understood only by context. </del> <ins> omitted (for example, a name of "www" derived from "www.example.net").  Such relative names are understood only by context. </ins> This term and its equivalent, "hostname", have been widely used but are not defined in RFC1034, RFC1035, RFC1123, or RFC2181.  The

Discussion:
The current definition says: The example is ambiguous. It should instead say:
PR is at URL
FWIW I still find it confusing. proposed alternative: The need for the term "fully qualified domain name" comes from the existence of partially qualified domain names, which are names where one or more of the later labels in the desired name are omitted. For example, a user may enter "www" and rely on the application or operating system to append an appropriate domain suffix, turning it into "URL". Such partially qualified names are understood only by context.
Hi, I’m a bit confused by “earliest” and “latest” here— Paul’s wording ("earliest labels in the ordered list”) made sense to me but Duane changed it (to “later labels in the desired list”). I’d suggest making it explicitly refer to "earlier labels in the ordering of nodes from the root of the tree,” because otherwise “earlier” or “later” both make my head hurt. Suzanne
My thinking was that as I read the name (e.g. left-to-right) the "www" part is earliest and the "URL" part is later. The way we talk about ordering of labels seems sort of fundamental and it would be a shame to have it buried in this one definition of FQDN. Its not really a terminology issue, but is there some way to make it more prominent and apply to the document as a whole?
Understood, was just thinking that it’s not obvious whether we mean reading order or evaluation order or something else unless we say so. Hadn't thought of it, but yes. This is where I’m reminded there’s not really a definition of “domain name” out there to incorporate. There’s been a proposed definition kicking around for awhile, which was briefly discussed somewhere (the arcing list?) and I tried to get Ed Lewis to add to draft-lewis-domain-name. I don’t think this document is the place to propose one not previously found in an RFC, although I’d be fine with the WG considering the question if the editors disagree. Suzanne
There is in fact a definition of "domain name" to incorporate.

Under "Global DNS", it says: We use "first" there, and we use it in a way that is the opposite of "earliest" in the current wording for FQDN, and thus the need for change. Duane's proposal is better than what we have now, but we can maybe even do better. How about:
Change:
The format of the IPv4 Captive-Portal DHCP option is shown below. <del> Code: The Captive-Portal DHCPv4 Option (160) (one octet) </del> <ins> Code: The Captive-Portal DHCPv4 Option (TBD) (one octet) </ins> Len: The length, in octets of the URI.

Discussion:
Forgot to make PR. This is the "good" one, should be abandoned...
Nope -- I think it is still TBD - we've asked / strongly suggested 114 in the IANA section, but I think it would feel presumptive to state that it is... W
I believe this should be changed to 114, or IANA-TBD.
Yikes, good catch. I changed it to TBD, and also added a sentence to the Abstract noting that it has changed from 160 to TBD (it seemed important enough). Thank you! W
NAME have changed or will change? I can't see this in the current version(s) of the draft here.
I swear I'd done this, and event sent a PR, but I cannot find it.... so, just made a new one...
I had created the branch, and made the edits, but apparently forgot to make the PR.... and then, because I couldn't find it, I made a new branch, change and PR (), and then realized the original was better, so I removed PR and created ... Oy vey, W
Done, had forgotten to close...
Should the TBDs be 114? Either that, or the list of changes should be TBD as well?
Change:
7.3.1. <del> This method is indicated by the method value "httpsig".  The signer creates an HTTP Message Signature as described in I-D.ietf-httpbis- message-signatures.  This method defines the following parameters: </del> <ins> This method is indicated by the method value "httpsig" and can be declared in either object form or string form. </ins> <del> The covered components of the signature MUST include the following: </del> <ins> When the proof method is specified in object form, the following parameters are defined: This example uses the ECDSA signing algorithm over the P384 curve and the SHA-256 hashing algorithm for the content digest. When the proof method is specified in string form, the signing algorithm MUST be derived from the key material (such as using the JWS algorithm in a JWK formatted key), and the content digest algorithm MUST be "sha-512". When using this method, the signer creates an HTTP Message Signature as described in I-D.ietf-httpbis-message-signatures.  The covered components of the signature MUST include the following: </ins> When the message contains a request body, the covered components MUST also include the following:

Discussion:
This reformats the object-type key proofs to be defined in terms of types, in parallel with interaction start methods. Now instead of default field values, you can have either an object with parameters or a string with strictly specified behavior. This should be less susceptible to confusion than the previous definition which allowed partial objects and implied a large set of possible combinations that the receiver would have to deal with.
To edit notification comments on pull requests, go to your .
Makes sense, it's aligned with the behaviour of the rest of the doc
Change:
4.5. <del> 4.5.1. </del> Each SFrame session uses a single ciphersuite that specifies the following primitives: <del> o A hash function This is used for the Key derivation and frame hashes for signature.  We recommend using SHA256 hash function. </del> <ins> o A hash function used for key derivation and hashing signature inputs o An AEAD encryption algorithm RFC5116 used for frame encryption, optionally with a truncated authentication tag </ins> <del> o An AEAD encryption algorithm [RFC5116] While any AEAD algorithm can be used to encrypt the frame, we recommend using algorithms with safe MAC truncation like AES-CTR and HMAC to reduce the per-frame overhead.  In this case we can use 80 bits MAC for video frames and 32 bits for audio frames similar to DTLS-SRTP cipher suites: </del> <ins> o [Optional] A signature algorithm </ins> <del> 1- AES_CM_128_HMAC_SHA256_80 </del> <ins> This document defines the following ciphersuites: </ins> <del> 2- AES_CM_128_HMAC_SHA256_32 </del> <ins> In the "AES_CM" suites, the length of the authentication tag is indicated by the last value: "_8" indicates an eight-byte tag and "_4" indicates a four-byte tag. In a session that uses multiple media streams, different ciphersuites might be configured for different media streams.  For example, in order to conserve bandwidth, a session might use a ciphersuite with 80-bit tags for video frames and another ciphersuite with 32-bit tags for audio frames. 4.5.1. </ins> <del> o [Optional] A signature algorithm If signature is supported, we recommend using ed25519 </del> <ins> In order to allow very short tag sizes, we define a synthetic AEAD function using the authenticated counter mode of AES together with HMAC for authentication.  We use an encrypt-then-MAC approach as in SRTP RFC3711. </ins> <del> 4.5.2. </del> <ins> Before encryption or decryption, encryption and authentication subkeys are derived from the single AEAD key using HKDF.  The subkeys are derived as follows, where "Nk" represents the key size for the AES block cipher in use and "Nh" represents the output size of the hash function: </ins> <del> SRTP is used as an HBH encryption, since the media payload is already encrypted, and SRTP only protects the RTP headers, one implementation could use 4 bytes outer auth tag to decrease the overhead, however it is up to the application to use other ciphers like AES-128-GCM with full authentication tag. </del> <ins> The AEAD encryption and decryption functions are then composed of individual calls to the CM encrypt function and HMAC.  The resulting MAC value is truncated to a number of bytes "tag_len" fixed by the ciphersuite. </ins> 5.

Discussion:
This PR revises the encryption procedures in a few ways: Ciphersuites for AES-GCM are now included The combination of AES-CM and SHA2 is spelled out, including an AAD length prefix to guard against confusion attacks We use the RFC 5116 AEAD interface (in particular, no separate auth tag) ... and as a result the tag truncation is internal to the AES-CM+SHA combination SFrame encryption now includes the encoded header as AAD Depends on
Change:
QUIC requires that the cryptographic handshake provide authenticated protocol negotiation.  TLS uses Application Layer Protocol <del> Negotiation (ALPN) RFC7301 to select an application protocol.  Unless </del> <ins> Negotiation (ALPN) ALPN to select an application protocol.  Unless </ins> another mechanism is used for agreeing on an application protocol, endpoints MUST use ALPN for this purpose.  When using ALPN, endpoints MUST immediately close a connection (see Section 10.3 in QUIC- TRANSPORT) if an application protocol is not negotiated with a no_application_protocol TLS alert (QUIC error code 0x178, see tls- <del> errors).  While RFC7301 only specifies that servers use this alert, QUIC clients MUST also use it to terminate a connection when ALPN </del> <ins> errors).  While ALPN only specifies that servers use this alert, QUIC clients MUST also use it to terminate a connection when ALPN </ins> negotiation fails. <del> An application-layer protocol MAY restrict the QUIC versions that it can operate over.  Servers MUST select an application protocol compatible with the QUIC version that the client has selected.  If the server cannot select a compatible combination of application protocol and QUIC version, it MUST abort the connection.  A client MUST abort a connection if the server picks an application protocol incompatible with the protocol version being used. </del> <ins> An application protocol MAY restrict the QUIC versions that it can operate over.  Servers MUST select an application protocol compatible with the QUIC version that the client has selected.  The server MUST treat the inability to select a compatible application protocol as a connection error of type 0x178 (no_application_protocol).  Similarly, a client MUST treat the selection of an incompatible application protocol by a server as a connection error of type 0x178. </ins> 8.2.

Discussion:
The old text used the non-specific "abort" here, but we can point to the right error code.
What does "abort" mean? Perhaps change this to "drop QUIC connection state"? Originally posted by NAME in URL
LGTM modulo the preference below.
Change:
functions defined in QUIC-TLS, packets that are smaller than 21 bytes are never valid. <ins> Endpoints MUST send stateless reset packets formatted as a packet with a short header.  However, endpoints MUST treat any packet ending in a valid stateless reset token as a stateless reset, as other QUIC versions might allow the use of a long header. </ins> An endpoint MAY send a stateless reset in response to a packet with a <del> long header.  This would not be effective if the stateless reset token was not yet available to a peer.  In this QUIC version, packets with a long header are only used during connection establishment. Because the stateless reset token is not available until connection establishment is complete or near completion, ignoring an unknown packet with a long header might be more effective. </del> <ins> long header.  Sending a stateless reset is not effective prior to the stateless reset token being available to a peer.  In this QUIC version, packets with a long header are only used during connection establishment.  Because the stateless reset token is not available until connection establishment is complete or near completion, ignoring an unknown packet with a long header might be as effective than sending a stateless reset. </ins> An endpoint cannot determine the Source Connection ID from a packet with a short header, therefore it cannot set the Destination

Discussion:
We don't want to prohibit the use of long headers in other versions - in case they want to share the stateless reset design, but there is no sense in sending long headers.
While I agree with the issue, the PR says that other versions might want to reset with a long header and therefore the receiver must inspect long headers anyway. I can see this, but given that, I think it is pointless to require the current version to only send resets for short headers. A general advice ought to suffice since the MUST is not enforceable anyway.
The requirement exists to protect those packets from detection.
Please don't close issues until AFTER consensus is declared (not just called).
I suspect Martin was confused because this issue was tagged has-proposal 15 days ago.
Right. The trigger is , not .
But it's understandable Martin would have assumed this was one of the issues that was sent out in the batch of issues a week and a half ago, given this has been tagged with has-proposal for 15 days.
Change:
5. <del> The following summarizes the set of information that is needed to configure DetNet MPLS over UDP/IP: </del> <ins> The following summarizes the minimum set of information that is needed to configure DetNet MPLS over UDP/IP: </ins> Label information (A-labels, S-labels and F-labels) to be mapped to UDP/IP flow.  Note that for example, a single S-Label can map

Discussion:
In chapter 5. Management and Control Information Summary one more bullet added + clarification text to the paragraph after the list.
Change:
requires additional Claims about the signer's time synchronization mechanism. <ins> In some use cases, however, a trustworthy clock might not be available.  For example, in many Trusted Execution Environments (TEEs) today, a clock is only available outside the TEE and so cannot be trusted by the TEE. </ins> 10.2. A second approach places the onus of timekeeping solely on the Verifier (for Evidence) or the Relying Party (for Attestation Results), and might be suitable, for example, in case the Attester <del> does not have a reliable clock or time synchronization is otherwise impaired.  In this approach, a non-predictable nonce is sent by the appraising entity, and the nonce is then signed and included along with the Claims in the Evidence or Attestation Result.  After checking that the sent and received nonces are the same, the </del> <ins> does not have a trustworthy clock or time synchronization is otherwise impaired.  In this approach, a non-predictable nonce is sent by the appraising entity, and the nonce is then signed and included along with the Claims in the Evidence or Attestation Result. After checking that the sent and received nonces are the same, the </ins> appraising entity knows that the Claims were signed after the nonce was generated.  This allows associating a "rough" epoch to the Evidence or Attestation Result.  In this case the epoch is said to be

Discussion:
Signed-off-by: Dave Thaler
At the IETF 110 meeting, Brendan Moran asked why local clocks are a problem since even MCUs have them. Currently we have text in the doc like... in the nonce section: in the handles section: I answered this by saying in the TEE use case for example, attesting the TEE needs a trusted clock, and having a trusted clock is not common. Brendan suggested clarifying the clock text.
Isn't it synchronized clocks that are the requirement? When you say "trusted clocks", do you mean, I can trust that they are securely synchronized? (Or that I can trust that Cesium still has that frequency, and that the laws of physics haven't been altered?)
I mean a clock for which code outside the TEE cannot tamper with. Whether it's synchronized or not is not about whether the clock itself is trusted. If a TEE wants to know how much time has passed since a previous event, and it has to ask the REE, and the REE can lie, then that clock is not trusted by the TEE.
Add text to TEE section about how it needs a local clock, and then add to the example involving nonces.
Change:
The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption.  Even when encrypted, a scheme could embed the unencrypted length of the <del> Connection ID in the Connection ID itself, instead of remembering it. </del> <ins> connection ID in the connection ID itself, instead of remembering it. </ins> <del> QUIC_LB further specified possible algorithms to generate Connection </del> <ins> QUIC_LB further specified possible algorithms to generate connection </ins> IDs at load balancers. 2.7.

Discussion:
We've not been capitalizing this in the main spec; so nor should this document. I've fixed those cases that I've touched in my upcoming PR, but it's going to need more work to clean up properly.
Yep, will do that after we merged the PRs. Thanks!
Change:
DNS API servers SHOULD use this well-known path to help contextualize DNS Query requests that use server push RFC7540. <del> A DNS API Client encodes the DNS query into the HTTP request using either the HTTP GET or POST methods. </del> <ins> A DNS API Client encodes a single DNS query into the HTTP request using either the HTTP GET or POST methods. </ins> When using the POST method the DNS query is included as the message body of the HTTP request and the Content-Type request header

Discussion:
… issue
It is not stated crystal clear in the -01 draft if there's only one DNS packet per HTTP request or if it is allowed to send more than one. Some wordings (like ) suggest a single packet. I think it would benefit the document to be more explicit on this detail.
good point - it is meant to be one, otherwise blocking and reordering (which is resolved at the intra-request http level) would be a problem. we'll add text.