jiebi/CodeConvo huggingface dataset:
7.1. <del> Senders MUST manage per-path congestion status, and MUST NOT send more data on a given path than congestion control on that path allows.  This is already a requirement of QUIC-TRANSPORT. </del> <ins> When the QUIC multipath extension is used, senders manage per-path congestion status as required in Section 9.4 of QUIC-TRANSPORT. However, in QUIC-TRANSPORT only one active path is assumed and as such the requirement is to reset the congestion control status on path migration.  With the multipath extension, multiple paths can be used simultaneously, therefore separate congestion control state is maintained for each path.  This means a sender is not allowed to send more data on a given path than congestion control for that path indicates. </ins> When a Multipath QUIC connection uses two or more paths, there is no guarantee that these paths are fully disjoint.  When two (or more
This proposal supports the negotiation of either the use of one packet number space for all paths or the use of separate packet <del> number spaces per path.  While separate packet number spaces allow for more efficient ACK encoding, especially when paths have highly different latencies, this approach requires the use of a connection ID.  Therefore use of a single number space can be beneficial in highly constrained networks that do not benefit from exposing the connection ID in the header.  While both approaches are supported by the specification in this version of the document, the intention for the final publication of a multipath extension for QUIC is to choose one option in order to avoid incompatibility.  More evaluation and </del> <ins> number spaces per path.  While both approaches are supported by the specification in this version of the document, the intention for the final publication of a multipath extension for QUIC is to choose one option in order to avoid incompatibility.  More evaluation and </ins> implementation experience is needed to select one approach before final publication.  Some discussion about pros and cons can be found here: https://github.com/mirjak/draft-lmbdhk-quic-
multipath negotiation is ambiguous, they MUST be interpreted as acknowledging packets sent on path 0. <ins> Endpoints negotiate the use of one packet number space for all paths or separate packet number spaces per path during the connection handshake nego.  While separate packet number spaces allow for more efficient ACK encoding, especially when paths have highly different latencies, this approach requires the use of a connection ID. Therefore use of a single number space can be beneficial when endpoints use zero-length connection ID for less overhead. </ins> 7.1. If the multipath option is negotiated to use one packet number space
this limit even applies when no connection ID is exposed in the QUIC header. <ins> This extension does not change the definition of any transport parameter defined in Section 18.2. of QUIC-TRANSPORT.  Inline with the definition in QUIC-TRANSPORT disable_active_migration also disables multipath support, except "after a client has acted on a preferred_address transport parameter" Section 18.2. of QUIC- TRANSPORT.  Further, it is out of scope for this document to specify if the old address can also be used for multipath after a client has migrated to the address provided in the preferred_address transport parameter.  However, it SHOULD NOT be assumed that it is possible to use both addresses simultaneously without further confirmation from the other host. </ins> 3. After completing the handshake, endpoints have agreed to enable
A relay MAY add information to requests if the client is aware of the nature of the information that could be added.  The client does not need to be aware of the exact value added for each request, but needs <del> to know the range of possible values the relay might use.  It is important to note that information added by the relay can reduce the </del> <ins> to know the range of possible values the relay might use. Importantly, information added by the relay - beyond what is already revealed through encapsulated requests from clients - can reduce the </ins> size of the anonymity set of clients at a gateway. Moreover, relays MAY apply differential treatment to clients that
request that is made to the target.  This means that only the gateway or target are in a position to identify abuse.  A gateway MAY send signals toward the relay to provide feedback about specific requests. <del> A relay that acts on this feedback could - either inadvertently or by design - lead to clients being deanonymized. </del> <ins> For example, a gateway could respond differently to requests it cannot decapsulate, as mentioned in errors.  A relay that acts on this feedback could - either inadvertently or by design - lead to client deanonymization. </ins> 7.2.2.
Oblivious Relay Resource also needs to observe the guidance in relay- responsibilities. <ins> An Oblivious Gateway Resource acts as a gateway for requests to the Target Resource (see HTTP).  The one exception is that any information it might forward in a response MUST be encapsulated, unless it is responding to errors it detects before removing encapsulation of the request; see errors. </ins> An Oblivious Gateway Resource, if it receives any response from the Target Resource, sends a single 200 response containing the encapsulated response.  Like the request from the client, this
information that does not reveal information about the encapsulated response. <del> An Oblivious Gateway Resource acts as a gateway for requests to the Target Resource (see HTTP).  The one exception is that any information it might forward in a response MUST be encapsulated, unless it is responding to errors it detects before removing encapsulation of the request; see errors. </del> In order to achieve the privacy and security goals of the protocol an Oblivious Gateway Resource also needs to observe the guidance in server-responsibilities.
indicate that the client configuration used to construct the request is incorrect or out of date. <ins> 5.3. The problem type PROBLEM of "https://iana.org/assignments/http- problem-types#ohttp-key" is defined.  An MAY use this problem type in a response to indicate that an used an outdated or incorrect . fig-key-problem shows an example response in HTTP/1.1 format. As this response cannot be encrypted, it might not reach the .  A cannot rely on the using this problem type.  A might also be configured to disregard responses that are not encapsulated on the basis that they might be subject to observation or modification by an .  A might manage the risk of an outdated using a heuristic approach whereby it periodically refreshes its if it receives a response with an error status code that has not been encapsulated. </ins> 6. In this design, a wishes to make a request of a server that is
9. Please update the "Media Types" registry at <del> https://www.iana.org/assignments/media-types [1] for the media types </del> <ins> https://iana.org/assignments/media-types [1] for the media types </ins> "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res). <ins> Please update the "HTTP Problem Types" registry at https://iana.org/assignments/http-problem-types [2] for the types "date" (iana-problem-date) and "ohttp-key" (iana-problem-ohttp-key). </ins> 9.1. The "application/ohttp-keys" media type identifies a used by
IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM. <ins> 9.5. IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM. </ins> 10.  References 10.1.  URIs <del> [1] https://www.iana.org/assignments/media-types </del> <ins> [1] https://iana.org/assignments/media-types [2] https://iana.org/assignments/http-problem-types </ins> Index
constructing and processing an . The Nenc parameter corresponding to the KEM used in HPKE can be found <del> in HPKE.  Nenc refers to the size of the encapsulated KEM shared secret, in bytes. </del> <ins> in HPKE or the HPKE KEM IANA registry [1].  Nenc refers to the size of the encapsulated KEM shared secret, in bytes. </ins> 4.2.
constructing and processing an . The Nn and Nk values correspond to parameters of the AEAD used in <del> HPKE, which is defined in HPKE.  Nn and Nk refer to the size of the AEAD nonce and key respectively, in bytes.  The nonce length is set to the larger of these two lengths, i.e., max(Nn, Nk). </del> <ins> HPKE, which is defined in HPKE or the HPKE AEAD IANA registry [2]. Nn and Nk refer to the size of the AEAD nonce and key respectively, in bytes.  The nonce length is set to the larger of these two lengths, i.e., max(Nn, Nk). </ins> 4.3.
9. Please update the "Media Types" registry at <del> https://iana.org/assignments/media-types [1] for the media types </del> <ins> https://iana.org/assignments/media-types [3] for the media types </ins> "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res). Please update the "HTTP Problem Types" registry at <del> https://iana.org/assignments/http-problem-types [2] for the types </del> <ins> https://iana.org/assignments/http-problem-types [4] for the types </ins> "date" (iana-problem-date) and "ohttp-key" (iana-problem-ohttp-key). 9.1.
10.1.  URIs <del> [1] https://iana.org/assignments/media-types </del> <ins> [1] https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kem-ids </ins> <del> [2] https://iana.org/assignments/http-problem-types </del> <ins> [2] https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-ids [3] https://iana.org/assignments/media-types [4] https://iana.org/assignments/http-problem-types </ins> Index
identified by "aead_id". The then constructs an , "enc_request", from a binary encoded HTTP <del> request, "request", as follows: </del> <ins> request BINARY, "request", as follows: </ins> Construct a message header, "hdr", by concatenating the values of "key_id", "kem_id", "kdf_id", and "aead_id", as one 8-bit integer
bhttp request", a zero byte, "key_id" as an 8-bit integer, plus "kem_id", "kdf_id", and "aead_id" as three 16-bit integers. <del> Create a receiving HPKE context by invoking "SetupBaseR()" (HPKE) with "skR", "enc", and "info".  This produces a context "rctxt". </del> <ins> Create a receiving HPKE context, "rctxt", by invoking "SetupBaseR()" (HPKE) with "skR", "enc", and "info". </ins> Decrypt "ct" by invoking the "Open()" method on "rctxt" (HPKE), with an empty associated data "aad", yielding "request" or an
In pseudocode, this procedure is as follows: <ins> The retains the HPKE context, "rctxt", so that it can encapsulate a response. </ins> 4.4. <del> Given an HPKE context, "context"; a request message, "request"; and a response, "response", generate an , "enc_response", as follows: </del> <ins> generate an , "enc_response", from a binary encoded HTTP response BINARY, "response".  The uses the HPKE receiver context, "rctxt", as the HPKE context, "context", as follows: </ins> Export a secret, "secret", from "context", using the string "message/bhttp response" as the "exporter_context" parameter to
In pseudocode, this procedure is as follows: <del> decrypt an by reversing this process.  That is, they first parse </del> <ins> decrypt an by reversing this process.  That is, first parse </ins> "enc_response" into "response_nonce" and "ct".  They then follow the <del> same process to derive values for "aead_key" and "aead_nonce". </del> <ins> same process to derive values for "aead_key" and "aead_nonce", using their sending HPKE context, "sctxt", as the HPKE context, "context". </ins> The uses these values to decrypt "ct" using the Open function provided by the AEAD.  Decrypting might produce an error, as follows:
requests over time.  However, this increases the risk that their request is rejected as outside the acceptable window. <ins> 6.9. The media type defined in ohttp-keys represents keying material.  The content of this media type is not active (see RFC6838), but it governs how a might interact with an .  The security implications of processing it are described in sec-client; privacy implications are described in privacy. The security implications of handling the message media types defined in req-res-media is covered in other parts of this section in more detail.  However, these message media types are also encrypted encapsulations of HTTP requests and responses. HTTP messages contain content, which can use any media type.  In particular, requests are processed by an Oblivious , which - as an HTTP resource - defines how content is processed; see HTTP.  HTTP clients can also use resource identity and response content to determine how content is processed.  Consequently, the security considerations of HTTP also apply to the handling of the content of these media types. </ins> 7. One goal of this design is that independent requests are only
Please update the "Media Types" registry at https://iana.org/assignments/media-types [2] for the media types "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), <del> and "message/ohttp-res" (iana-res). </del> <ins> and "message/ohttp-res" (iana-res), following the procedures of RFC6838. </ins> Please update the "HTTP Problem Types" registry at https://iana.org/assignments/http-problem-types [3] for the types
Including a "Date" header field in the response allows the to correct clock errors by retrying the same request using the value of the "Date" field provided by the .  The value of the "Date" field can be <del> copied if the request is fresh, with an adjustment based on the "Age" field otherwise.  When retrying a request, the MUST create a fresh encryption of the modified request, using a new HPKE context. </del> <ins> copied if the response is fresh, with an adjustment based on the "Age" field otherwise; see HTTP-CACHING.  When retrying a request, the MUST create a fresh encryption of the modified request, using a new HPKE context. Retrying immediately allows the to measure the round trip time to the . The observed delay might reveal something about the location of the .  could delay retries to add some uncertainty to any observed delay. </ins> Intermediaries can sometimes rewrite the "Date" field when forwarding responses.  This might cause problems if the and intermediary clocks
the public key from the configuration, "pkR", and <del> a selected combination of KDF, identified by "kdf_id", and AEAD, identified by "aead_id". </del> <ins> a combination of KDF, identified by "kdf_id", and AEAD, identified by "aead_id", that the selects from those in the . </ins> The then constructs an , "enc_request", from a binary encoded HTTP request BINARY, "request", as follows:
The types HpkeKemId, HpkeKdfId, and HpkeAeadId identify a KEM, KDF, and AEAD respectively.  The definitions for these identifiers and the <del> semantics of the algorithms they identify can be found in HPKE. </del> <ins> semantics of the algorithms they identify can be found in HPKE.  The Npk parameter corresponding to the HpkeKdfId can be found in HPKE. </ins> 4.2.
encapsulation key "enc". Construct associated data, "aad", by concatenating the values of <del> "keyID", "kdfID", and "aeadID", as 8-, 16- and 16-bit integers respectively, each in network byte order. </del> <ins> "keyID", "kemID", "kdfID", and "aeadID", as one 8-bit integer and three 16-bit integers, respectively, each in network byte order. </ins> Encrypt (seal) "request" with "aad" as associated data using "context", yielding ciphertext "ct".
Servers decrypt an Encapsulated Request by reversing this process. Given an Encapsulated Request "enc_request", a server: <del> Parses "enc_request" into "keyID", "kdfID", "aeadID", "enc", and "ct" (indicated using the function "parse()" in pseudocode).  The server is then able to find the HPKE private key, "skR", corresponding to "keyID". </del> <ins> Parses "enc_request" into "keyID", "kemID", "kdfID", "aeadID", "enc", and "ct" (indicated using the function "parse()" in pseudocode).  The server is then able to find the HPKE private key, "skR", corresponding to "keyID". </ins> <del> a.  If "keyID" does not identify a key, the server returns an error. </del> <ins> a.  If "keyID" does not identify a key matching the type of "kemID", the server returns an error. </ins> b.  If "kdfID" and "aeadID" identify a combination of KDF and AEAD that the server is unwilling to use with "skR", the server returns
the QUIC header, if present.  This supports cases where address information changes, such as NAT rebinding, intentional change of the local interface, or based on an indication in the handshake of the <del> server for a preferred address to be used. </del> <ins> server for a preferred address to be used.  As such if the client is known or likely to sit behind a NAT, use of a connection ID for the server is strongly recommended.  A non-empty connection ID for the server is also strongly recommended when migration is supported. </ins> Currently QUIC only supports failover cases.  Only one "path" can be used at a time, and only when the new path is validated all traffic
characteristics as input for the switching decision or the congestion controller on the new path. <ins> Only the client can actively migrate.  However, servers can indicate during the handshake that they prefer to transfer the connection to a different address after the handshake, e.g. to move from an address that is shared by multiple servers to an address that is unique to the server instance.  The server can provide an IPv4 and an IPv6 address in a transport parameter during the TLS handshake and the client can select between the two if both are provided.  See also Section 9.6 of QUIC. </ins> 8. QUIC connections are closed either by expiration of an idle timeout,
changes under discussion, via issues and pull requests in GitHub current as of the time of writing. <del> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> 2. In this section, we discusses those aspects of the QUIC transport
header, is integrity protected.  Further, information that was sent and exposed in handshake packets sent before the cryptographic context was established are validated later during the cryptographic <del> handshake.  Therefore, devices on path MUST NOT change any information or bits in QUIC packet headers, since alteration of header information will lead to a failed integrity check at the receiver, and can even lead to connection termination. </del> <ins> handshake.  Therefore, devices on path cannot alter any information or bits in QUIC packet headers, since alteration of header information will lead to a failed integrity check at the receiver, and can even lead to connection termination. </ins> 2.6.
applicability, and issues that application developers must consider when using QUIC as a transport for their application. <del> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> 2. QUIC uses UDP as a substrate.  This enables both userspace
packet is visible to the network.  Therefore stream multiplexing is not intended to be used for differentiating streams in terms of network treatment.  Application traffic requiring different network <del> treatment SHOULD therefore be carried over different five-tuples </del> <ins> treatment should therefore be carried over different five-tuples </ins> (i.e.  multiple QUIC connections).  Given QUIC's ability to send application data in the first RTT of a connection (if a previous connection to the same host has been successfully established to
example, the default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. <del> Applications SHOULD define an alternate endpoint discovery mechanism </del> <ins> Applications should define an alternate endpoint discovery mechanism </ins> to allow the usage of ports other than the default.  For example, HTTP/3 (QUIC-HTTP sections 3.2 and 3.3) specifies the use of ALPN RFC7301 for service discovery which allows the server to use and
applications using QUIC, as well. Application developers should note that any fallback they use when <del> QUIC cannot be used due to network blocking of UDP SHOULD guarantee </del> <ins> QUIC cannot be used due to network blocking of UDP should guarantee </ins> the same security properties as QUIC; if this is not possible, the <del> connection SHOULD fail to allow the application to explicitly handle </del> <ins> connection should fail to allow the application to explicitly handle </ins> fallback to a less-secure alternative.  See fallback. 14.
handshake packets sent before the cryptographic context was established are validated later during the cryptographic handshake. Therefore, devices on path cannot alter any information or bits in <del> QUIC packet headers, since alteration of header information will lead to a failed integrity check at the receiver, and can even lead to connection termination. </del> <ins> QUIC packet headers, except specific parts of Initial packets, since alteration of header information will lead to a failed integrity check at the receiver, and can even lead to connection termination. </ins> 2.6.
renders 5-tuple based filtering insufficient and requires more state to be maintained by DDoS defense systems.  For the common case of NAT rebinding, DDoS defense systems can detect a change in the client's <del> endpoint address by linking flows based on the first 8 bytes of the server's connection IDs, provided the server is using at least 8- bytes-long connection IDs.  QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID and necessitates that connection ID-aware DDoS defense system must have the same information about connection IDs as the load balancer I-D.ietf-quic-load-balancers.  This may be complicated where mitigation and load balancing environments are logically separate. </del> <ins> endpoint address by linking flows based on the server's connection IDs.  QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID. </ins> It is questionable whether connection migrations must be supported during a DDoS attack.  If the connection migration is not visible to
stream by instructing QUIC to send a FIN bit in a STREAM frame.  It cannot gracefully close the ingress direction without a peer- generated FIN, much like in TCP.  However, an endpoint can abruptly <del> close either the ingress or egress direction; these actions are fully independent of each other. </del> <ins> close the egress direction or request that its peer abruptly close the ingress direction; these actions are fully independent of each other. </ins> QUIC does not provide an interface for exceptional handling of any stream.  If a stream that is critical for an application is closed,
As QUIC is a general purpose transport protocol, there are no requirements that servers use a particular UDP port for QUIC.  For applications with a fallback to TCP that do not already have an <del> alternate mapping to UDP, the registration (if necessary) and use of the UDP port number corresponding to the TCP port already registered for the application is RECOMMENDED.  For example, the default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. </del> <ins> alternate mapping to UDP, usually the registration (if necessary) and use of the UDP port number corresponding to the TCP port already registered for the application is appropriate.  For example, the default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. </ins> Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example,