requires negotiation between the two endpoints using a new transport parameter, as specified in nego. <del> This proposal supports the negotiation of either the use of one packet number space for all paths or the use of separate packet 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 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/blob/master/presentations/PacketNumberSpace_s.pdf As currently defined in this version of the draft the use of multiple packet number spaces requires the use of connection IDs is both directions.  Today's deployments often only use destination connection ID when sending packets from the client to the server as this addresses the most important use cases for migration, like NAT rebinding or mobility events.  Further discussion and work is required to evaluate if the use of multiple packet number spaces could be supported as well when the connection ID is only present in one direction. </del> <ins> This extension uses multiple packet number spaces.  When multipath is negotiated, each destination connection ID is linked to a separate packet number space.  Using multiple packet number spaces enables direct use of the loss recovery and congestion control mechanisms defined in QUIC-RECOVERY. Some deployments of QUIC use zero-length connection IDs.  When a node selects to use zero-length connection IDs, it is not possible to use different connection IDs for distinguishing packets sent to that node over different paths.  This extension also specifies a way to use zero-length CID by using the same packet number space on all paths. However, when using the same packet number space on multiple paths, out of order delivery is likely.  This causes inflation of the number of acknowledgement ranges and therefore of the the size of ACK frames.  Senders that accept to use a single number space on multiple paths when sending to a node using zero-length CID need to take special care to minimize the impact of multipath delivery on loss detection, congestion control, and ECN handling.  This proposal specifies algorithms for controlling the size of acknowledgement packets and ECN handling in Section using-zero-length and ecn- handling. </ins> This proposal does not cover address discovery and management. Addresses and the actual decision process to setup or tear down paths


param_value_definition : If for any one of the endpoints the parameter is absent or set to 0, <del> or if the two endpoints select incompatible values, one proposing 0x1 and the other proposing 0x2, the endpoints MUST fallback to QUIC- TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document. If an endpoint proposes the value 0x3, the value proposed by the other is accepted.  If both endpoints propose the value 0x3, the value 0x2 is negotiated. </del> <ins> the endpoints MUST fallback to QUIC-TRANSPORT with single active path and MUST NOT use any frame or mechanism defined in this document. </ins> If endpoint receives unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type


multipath negotiation is ambiguous, they MUST be interpreted as acknowledging packets sent on path 0. <del> 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. </del> 7.1. <del> If the multipath option is negotiated to use one packet number space for all paths, the packet sequence numbers are allocated from the common number space, so that, for example, packet number N could be sent on one path and packet number N+1 on another. ACK frames report the numbers of packets that have been received so far, regardless of the path on which they have been received.  That means the senders needs to maintain an association between sent packet numbers and the path over which these packets were sent.  This is necessary to implement per path congestion control. When a packet is acknowledged, the state of the congestion control MUST be updated for the path where the acknowledged packet was originally sent.  The RTT is calculated based on the delay between the transmission of that packet and its first acknowledgement (see compute-rtt) and is used to update the RTT statistics for the sending path. Also loss detection MUST be adapted to allow for different RTTs on different paths.  For example, timer computations should take into account the RTT of the path on which a packet was sent.  Detections based on packet numbers shall compare a given packet number to the highest packet number received for that path. </del> <ins> If a zero-length connection ID is used, one packet number space for all paths.  That means the packet sequence numbers are allocated from the common number space, so that, for example, packet number N could be sent on one path and packet number N+1 on another. In this case, ACK frames report the numbers of packets that have been received so far, regardless of the path on which they have been received.  That means the senders needs to maintain an association between sent packet numbers and the path over which these packets were sent.  This is necessary to implement per path congestion control, as explained in zero-length-cid-loss-and-congestion. Further, the receiver of packets with zero-length connection IDs should implement handling of acknowledgements as defined in sending- acknowledgements-and-handling-ranges. ECN handing is specified in ecn-handling, and mitigation of the RTT measurement is further explained in ack-delay-and-zero-length-cid- considerations. If a node does not want to implement this logic, it MAY instead limit its use of multiple paths as explained in restricted-sending-to-zero- length-cid-peer. </ins> 7.1.1. <ins> If zero-length CID and therefore also a single packet number space is used by the sender, the receiver MAY send ACK frames instead of ACK_MP frames to reduce overhead as the additional path ID field will anyway always carry the same value. </ins> If senders decide to send packets on paths with different transmission delays, some packets will very likely be received out of order.  This will cause the ACK frames to carry multiple ranges of


7.1.2. <ins> When sending to a zero-length CID receiver, senders may receive acknowledgements that combine packet numbers received over multiple paths.  However, even if one packet number space is used on multiple path the sender MUST maintain separate congestion control state for each path.  Therefore, senders MUST be able to infer the sending path from the acknowledged packet numbers, for example by remembering which packet was sent on what path.  The senders MUST use that information to perform congestion control on the relevant paths, and to correctly estimate the transmission delays on each path.  (See ack-delay-and-zero-length-cid-considerations for specific considerations about using the ACK Delay field of ACK frames, and ecn-handling for issues on using ECN marks.) Loss detection as specified in QUIC-RECOVERY uses algorithms based on timers and on sequence numbers.  When packets are sent over multiple paths, loss detection must be adapted to allow for different RTTs on different paths.  When sending to zero-length CID receivers, packets sent on different paths may be received out of order.  Therefore senders cannot directly use the packet sequence numbers to compute the Packet Thresholds defined in Section 6.1.1 of QUIC-RECOVERY. Relying only on Time Thresholds produces correct results, but is somewhat suboptimal.  Some implementations have been getting good results by not just remembering the path over which a packet was sent, but also maintaining an order list of packets sent on each path.  That ordered list can then be used to compute acknowledgement gaps per path in Packet Threshold tests. 7.1.3. </ins> The ACK Delay field of the ACK frame is relative to the largest acknowledged packet number (see Section 13.2.5 of QUIC-TRANSPORT). When using paths with different transmission delays, the reported


latency.  To collect ACK delays on all the paths, hosts should rely on time stamps as described in QUIC-Timestamp. <ins> 7.1.4. ECN feedback in QUIC is provided based on counters in the ACK frame (see Section 19.3.2. of QUIC-TRANSPORT).  That means if an ACK frame acknowledges multiple packets, the ECN feedback cannot be accounted to a specific packet. There are separate counters for each packet number space.  However, sending to zero-length CID receivers, the same number space is used for multiple paths.  Respectively, if an ACK frames acknowledges multiple packets from different paths, the ECN feedback cannot unambiguously be assigned to a path. If the sender marks its packets with the ECN capable flags, the network will expect standard reactions to ECN marks, such as slowing down transmission on the sending path.  If zero-length CID is used, the sending path is however ambiguous.  Therefore, the sender MUST treat a CE marking as a congestion signal on all sending paths that have been by a packet that was acknowledged in the ACK frame signaling the CE counter increase. A host that is sending over multiple paths to a zero-length CID receiver MAY disable ECN marking and send all subsequent packets as Not-ECN capable. 7.1.5. Hosts that are designed to support multipath using multiple number spaces MAY adopt a conservative posture after negotiating multipath support with a peer using zero-length CID.  The simplest posture is to only send data on one path at a time, while accepting packets on all acceptable paths.  In that case: the attribution of packets to path discussed in zero-length-cid- loss-and-congestion are easy to solve because packets are sent on a single path, the ACK Delays are correct, the vast majority of ECN marks relate to the current sending path. Of course, the hosts will only take limited advantage from the multipath capability in these scenarios.  Support for "make before break" migrations will improve, but load sharing between multiple paths will not work. </ins> 7.2. <del> If the multipath option is enabled with a value of 2, each path has its own packet number space for transmitting 1-RTT packets and a new ACK frame format is used as specified in ack-mp-frame.  Compared to the QUIC version 1 ACK frame, the ACK_MP frames additionally contains a Packet Number Space Identifier (PN Space ID).  The PN Space ID used to distinguish packet number spaces for different paths and is simply </del> <ins> If packets contain a non-zero CID, each path has its own packet number space for transmitting 1-RTT packets and a new ACK frame format is used as specified in ack-mp-frame.  Compared to the QUIC version 1 ACK frame, the ACK_MP frames additionally contains a Packet Number Space Identifier (PN Space ID).  The PN Space ID used to distinguish packet number spaces for different paths and is simply </ins> derived from the sequence number of Destination Connection ID. Therefore, the packet number space for 1-RTT packets can be identified based on the Destination Connection ID in each packets.


threshold, or the quality of RTT or loss rate is becoming worse) and wants to close the initial path. <del> In Figure fig-example-path-close the server's 1-RTT packets use DCID C1, which has a sequence number of 1, for the first path; the client's 1-RTT packets use DCID S2, which has a sequence number of 2. For the second path, the server's 1-RTT packets use DCID C2, which has a sequence number of 2; the client's 1-RTT packets use CID S3, which has a sequence number of 3.  Note that two paths use different packet number space. The client initiates the path closure for the path with ID 1 by sending a packet with an PATH_ABANDON frame.  When the server received the PATH_ABANDON frame, it also sends an PATH_ABANDON frame in the next packet.  Afterwards the connection IDs in both directions can be retired using the RETIRE_CONNECTION_ID frame. </del> <ins> fig-example-path-close1 illustrates an example of path closing when both the client and the server use non-zero-length CIDs.  For the first path, the server's 1-RTT packets use DCID C1, which has a sequence number of 1; the client's 1-RTT packets use DCID S2, which has a sequence number of 2.  For the second path, the server's 1-RTT packets use DCID C2, which has a sequence number of 2; the client's 1-RTT packets use DCID S3, which has a sequence number of 3.  Note that the paths use different packet number spaces.  In this case, the client is going to close the first path.  It identifies the path by the sequence number of the received packet's DCID over that path (path identifier type 0x00), hence using the path_id 1.  Optionally, the server confirms the path closure by sending an PATH_ABANDON frame using the sequence number of the received packet's DCID over that path (path identifier type 0x00) as path identifier, which corresponds to the path_id 2.  Both the client and the server can close the path after receiving the RETIRE_CONNECTION_ID frame for that path. fig-example-path-close2 illustrates an example of path closing when the client chooses to receive zero-length CIDs while the server chooses to receive non-zero-length CIDs.  Because there is a zero- length CID in one direction, single packet number spaces are used. For the first path, the client's 1-RTT packets use DCID S2, which has a sequence number of 2.  For the second path, the client's 1-RTT packets use DCID S3, which has a sequence number of 3.  Again, in this case, the client is going to close the first path.  Because the client now receives zero-length CID packets, it needs to use path identifier type 0x01, which identifies a path by the DCID sequence number of the packets it sends over that path, and hence, it uses a path_id 2 in its PATH_ABANDON frame.  The server SHOULD stop sending new data on the path indicated by the PATH_ABANDON frame after receiving it.  However, The client may want to repeat the PATH_ABANDON frame if it sees the server continuing to send data. When the client's PATH_ABANDON frame is acknowledged, it sends out a RETIRE_CONNECTION_ID frame for the CID used on the first path.  The server can readily close the first path when it receives the RETIRE_CONNECTION_ID frame from the client.  However, since the client will not receive a RETIRE_CONNECTION_ID frame, after sending out the RETIRE_CONNECTION_ID frame, the client waits for 3 RTO before closing the path. </ins> 11.


When the multipath option is negotiated, clients that want to use an additional path MUST first initiate the Address Validation procedure <del> with PATH_CHALLENGE and PATH_RESPONSE frames described in Section 8 of QUIC-TRANSPORT.  After receiving packets from the client on the new paths, the servers MAY in turn attempt to validate these paths using the same mechanisms. </del> <ins> with PATH_CHALLENGE and PATH_RESPONSE frames described in Section 8.2 of QUIC-TRANSPORT.  After receiving packets from the client on a new path, if the server decides to use the new path, the server MUST perform path validation Section 8.2 of QUIC-TRANSPORT unless it has previously validated that address. </ins> If validation succeed, the client can send non-probing, 1-RTT packets on the new paths.  In contrast with the specification in Section 9 of


provides several general-purpose packet schedulers depending on the application goals. <ins> Note that the receiver could use a different scheduling strategy to send ACK(_MP) frames.  The recommended default behaviour consists in sending ACK(_MP) frames on the path they acknowledge packets.  Other scheduling strategies, such as sending ACK(_MP) frames on the lowest latency path, might be considered, but they could impact the sender with side effects on, e.g., the RTT estimation or the congestion control scheme.  When adopting such asymetrical acknowledgment scheduling, the receiver should at least ensure that the sender negotiated one-way delay calculation mechanism (e.g., QUIC- Timestamp). </ins> 8. Simultaneous use of multiple paths enables different retransmission


If endpoint receives an unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type <del> MP_CONNECTION_ERROR and close the connection. </del> <ins> TRANSPORT_PARAMETER_ERROR (specified in Section 20.1 of QUIC- TRANSPORT) and close the connection. </ins> This extension does not change the definition of any transport parameter defined in Section 18.2. of QUIC-TRANSPORT.


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:


respectively. In order to achieve the privacy and security goals of the protocol a <del> also needs to observe the guidance in client-responsibilities. </del> <ins> also needs to observe the guidance in sec-client. </ins> The interacts with the as an HTTP client by constructing a request using the same restrictions as the request, except that the target


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.


enc-request. request describes the process for constructing and processing an Encapsulated Request. <ins> The Nenc parameter corresponding to the HpkeKdfId can be found in HPKE. </ins> Responses are bound to responses and so consist only of AEAD- protected content.  response describes the process for constructing and processing an Encapsulated Response.


Clients encapsulate a request "request" using values from a key configuration: <del> the key identifier from the configuration, "keyID", </del> <ins> the key identifier from the configuration, "keyID", with the corresponding KEM identified by "kemID", </ins> the public key from the configuration, "pkR", and


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.


given that establishing a new connection using 0-RTT support is cheap and fast. <del> QoS mechanisms in the network MAY also use the connection ID for </del> <ins> QoS mechanisms in the network could also use the connection ID for </ins> service differentiation, as a change of connection ID is bound to a change of address which anyway is likely to lead to a re-route on a different path with different network characteristics.


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


even if TFO was successfully negotiated (see PaaschNanog). Any fallback mechanism is likely to impose a degradation of <del> performance; however, fallback MUST not silently violate the </del> <ins> performance; however, fallback must not silently violate the </ins> application's expectation of confidentiality or integrity of its payload data.


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,


Given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of ports that cannot easily be mapped to a registered service name might <del> lead to blocking or other interference by network elements such as firewalls that rely on the port number for application identification. </del> <ins> lead to blocking or other changes to the forwarding behavior by network elements such as firewalls that use the port number for application identification. </ins> 7.


13. <del> QUIC provides integrity protection for its version negotiation process.  This process assumes that the set of versions that a server supports is fixed.  This complicates the process for deploying new QUIC versions or disabling old versions when servers operate in </del> <ins> QUIC version 1 does not specify a version negotation mechanism in the base spec but I-D.draft-ietf-quic-version-negotiation proposes an extension.  This process assumes that the set of versions that a server supports is fixed.  This complicates the process for deploying new QUIC versions or disabling old versions when servers operate in </ins> clusters. A server that rolls out a new version of QUIC can do so in three


a solution to this problem.  However, hiding information about the change of the IP address or port conceals important and security- relevant information from QUIC endpoints and as such would facilitate <del> amplification attacks (see section 9 of QUIC-TRANSPORT).  An NAT </del> <ins> amplification attacks (see Section 9 of QUIC-TRANSPORT).  A NAT </ins> function that hides peer address changes prevents the other end from detecting and mitigating attacks as the endpoint cannot verify connectivity to the new address using QUIC PATH_CHALLENGE and


to use smaller packets, so that the limited reassembly capacity is not exceeded. <del> For TCP, MSS clamping (Section 3.2 of {?RFC4459}}) is often used to </del> <ins> For TCP, MSS clamping (Section 3.2 of RFC4459) is often used to </ins> change the sender's maximum TCP segment size, but QUIC requires a different approach.  Section 14 of QUIC-TRANSPORT advises senders to probe larger sizes using Datagram Packetization Layer PMTU Discovery


14. <del> I-D.draft-ietf-quic-datagram specifies a QUIC extension to enable sending and receiving unreliable datagrams over QUIC.  Unlike operating directly over UDP, applications that use the QUIC datagram service do not need to implement their own congestion control, per RFC8085, as QUIC datagrams are congestion controlled. </del> <ins> I-D.ietf-quic-datagram specifies a QUIC extension to enable sending and receiving unreliable datagrams over QUIC.  Unlike operating directly over UDP, applications that use the QUIC datagram service do not need to implement their own congestion control, per RFC8085, as QUIC datagrams are congestion controlled. </ins> QUIC datagrams are not flow-controlled, and as such data chunks may be dropped if the receiver is overloaded.  While the reliable


cause long timeout-based delays before this problem is detected by the endpoints and the connection can potentially be re-established. <del> QUIC endpoints support address migration and a QUIC connection can survive a change of the IP address or ports by mapping the connection ID, if present, to an existing connection.  Ideally a new connection ID is used at the same time when the address/port changes to avoid linkability.  As new connection IDs belonging to the same connection are not known to on-path devices, network devices are not able to map QUIC connections after a 4-tuple change.  As such, when the 4-tuple changes, stateful devices lose their state and break connectivity if state is required for forwarding, while the endpoints would otherwise survive such a change. </del> Use of connection IDs is specifically discouraged for NAT applications.  If a NAT hits an operational limit, it is recommended to rather drop the initial packets of a flow (see also sec-


impacted by QUIC. QUIC is an end-to-end transport protocol.  No information in the <del> protocol header, even that which can be inspected, is meant to be mutable by the network.  This is achieved through integrity protection of the wire image WIRE-IMAGE.  Encryption of most control signaling means that less information is visible to the network than is the case with TCP. </del> <ins> protocol header, even that which can be inspected, is mutable by the network.  This is achieved through integrity protection of the wire image WIRE-IMAGE.  Encryption of most control signaling means that less information is visible to the network than is the case with TCP. </ins> Integrity protection can also simplify troubleshooting, because none of the nodes on the network path can modify transport layer <del> information.  However, it does imply that in-network operations that depend on modification of data are not possible without the cooperation of a QUIC endpoint.  This might be possible with the introduction of a proxy which authenticates as an endpoint.  Proxy operations are not in scope for this document. </del> <ins> information.  However, it means in-network operations that depend on modification of data are not possible without the cooperation of an QUIC endpoint.  This might be possible with the introduction of a proxy which authenticates as an endpoint.  Proxy operations are not in scope for this document. </ins> Network management is not a one-size-fits-all endeavour: practices considered necessary or even mandatory within enterprise networks


which type of header is present.  The purpose of this bit is invariant across QUIC versions. <del> The long header exposes more information.  In version 1 of QUIC, it is used during connection establishment, including version negotiation, retry, and 0-RTT data.  It contains a version number, as well as source and destination connection IDs for grouping packets belonging to the same flow.  The definition and location of these fields in the QUIC long header are invariant for future versions of QUIC, although future versions of QUIC may provide additional fields in the long header QUIC-INVARIANTS. </del> <ins> The long header exposes more information.  It contains a version number, as well as source and destination connection IDs for associating packets with a QUIC connection.  The definition and location of these fields in the QUIC long header are invariant for future versions of QUIC, although future versions of QUIC may provide additional fields in the long header QUIC-INVARIANTS. In version 1 of QUIC, the long header is used during connection establishment to transmit crypto handshake data, perform version negotiation, retry, and send 0-RTT data. </ins> Short headers contain only an optional destination connection ID and the spin bit for RTT measurement.  In version 1 of QUIC, they are


identifies the packet as a Version Negotiation packet.  QUIC version 1 uses version 0x00000001.  Operators should expect to observe packets with other version numbers as a result of various <del> Internet experiments, future standards, and greasing.  All deployed versions are maintained in an IANA registry (see </del> <ins> Internet experiments, future standards, and greasing (RFC7801). All deployed versions are maintained in an IANA registry (see </ins> Section 22.2 of QUIC-TRANSPORT). source and destination connection ID: short and long packet


packet number: All packets except Version Negotiation and Retry packets have an associated packet number; however, this packet number is encrypted, and therefore not of use to on-path <del> observers.  The offset of the packet number is encoded in long </del> <ins> observers.  The offset of the packet number can be decoded in long </ins> headers, while it is implicit (depending on destination connection ID length) in short headers.  The length of the packet number is cryptographically obfuscated.


Server Initial datagram as shown in fig-server-initial typically containing three packets: an Initial packet with the beginning of the server's side of the TLS handshake, a Handshake packet with the rest <del> of the server's side of the TLS handshake, and initial 1-RTT data, if </del> <ins> of the server's side of the TLS handshake, and 1-RTT data, if </ins> present. The Client Completion datagram contains at least one Handshake packet


Even though transport parameters transmitted in the client's Initial packet are observable by the network, they cannot be modified by the <del> network without risking connection failure.  Further, the reply from </del> <ins> network without causing connection failure.  Further, the reply from </ins> the server cannot be observed, so observers on the network cannot know which parameters are actually in use.


3.2. <del> This document focuses on QUIC version 1, and this section applies only to packets belonging to QUIC version 1 flows; for purposes of on-path observation, it assumes that these packets have been identified as such through the observation of a version number exchange as described above. </del> <ins> This document focuses on QUIC version 1, and this Connection Confirmation section applies only to packets belonging to QUIC version 1 flows; for purposes of on-path observation, it assumes that these packets have been identified as such through the observation of a version number exchange as described above. </ins> Connection establishment uses Initial and Handshake packets containing a TLS handshake, and Retry packets that do not contain


detected using heuristics similar to those used to detect TLS over TCP.  A client initiating a connection may also send data in 0-RTT packets directly after the Initial packet containing the TLS Client <del> Hello.  Since these packets may be reordered in the network, 0-RTT </del> <ins> Hello.  Since packets may be reordered or lost in the network, 0-RTT </ins> packets could be seen before the Initial packet. Note that in this version of QUIC, clients send Initial packets


3.4.1. <del> If the ClientHello is not encrypted, it can be derived from the </del> <ins> If the ClientHello is not encrypted, SNI can be derived from the </ins> client's Initial packet by calculating the Initial secret to decrypt the packet payload and parsing the QUIC CRYPTO Frame containing the TLS ClientHello.


An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS exposes control information to modification and manipulation in the network.  Further <del> downgrades to older TLS versions than used in QUIC, which is 1.3, might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. </del> <ins> downgrades to older TLS versions than 1.3, which is used in QUIC version 1, might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. </ins> These applications must operate, perhaps with impaired functionality, in the absence of features provided by QUIC not present in the


Priority handling of retransmissions can be implemented by the sender in the transport layer.  QUIC recommends retransmitting lost data before new data, unless indicated differently by the application. <del> Currently, QUIC only provides fully reliable stream transmission, which means that prioritization of retransmissions will be beneficial in most cases, by filling in gaps and freeing up the flow control window.  For partially reliable or unreliable streams, priority scheduling of retransmissions over data of higher-priority streams might not be desirable.  For such streams, QUIC could either provide an explicit interface to control prioritization, or derive the prioritization decision from the reliability level of the stream. </del> <ins> When a QUIC endpoint uses fully reliable streams for transmission, prioritization of retransmissions will be beneficial in most cases, filling in gaps and freeing up the flow control window.  For partially reliable or unreliable streams, priority scheduling of retransmissions over data of higher-priority streams might not be desirable.  For such streams, QUIC could either provide an explicit interface to control prioritization, or derive the prioritization decision from the reliability level of the stream. </ins> 4.3.


making further progress.  At this stage connections can be terminated via idle timeout or explicit close; see sec-termination). <del> An application that uses QUIC might communicate a cumulative stream limit but require the connection to be closed before the limit is </del> <ins> An application that uses QUIC and communicated a cumulative stream limit might require the connection to be closed before the limit is </ins> reached.  For example, to stop the server to perform scheduled maintenance.  Immediate connection close causes abrupt closure of actively used streams.  Depending on how an application uses QUIC streams, this could be undesirable or detrimental to behavior or <del> performance.  A more graceful closure technique is to stop sending increases to stream limits and allow the connection to naturally terminate once remaining streams are consumed.  However, the period of time it takes to do so is dependent on the client and an unpredictable closing period might not fit application or operational needs.  Applications using QUIC can be conservative with open stream limits in order to reduce the commitment and indeterminism.  However, being overly conservative with stream limits affects stream concurrency.  Balancing these aspects can be specific to applications and their deployments.  Instead of relying on stream limits to avoid abrupt closure, an application-layer graceful close mechanism can be used to communicate the intention to explicitly close the connection at some future point. HTTP/3 provides such a mechanism using the GOAWAY frame.  In HTTP/3, when the GOAWAY frame is received by a client, it stops opening new streams even if the cumulative stream limit would allow.  Instead the client would create a new connection on which to open further streams.  Once all streams are closed on the old connection, it can be terminated safely by a connection close or after expiration of the idle time out (see also sec-termination). </del> <ins> performance. A more graceful closure technique is to stop sending increases to stream limits and allow the connection to naturally terminate once remaining streams are consumed.  However, the period of time it takes to do so is dependent on the peer and an unpredictable closing period might not fit application or operational needs.  Applications using QUIC can be conservative with open stream limits in order to reduce the commitment and indeterminism.  However, being overly conservative with stream limits affects stream concurrency.  Balancing these aspects can be specific to applications and their deployments. Instead of relying on stream limits to avoid abrupt closure, an application-layer graceful close mechanism can be used to communicate the intention to explicitly close the connection at some future point.  HTTP/3 provides such a mechanism using the GOAWAY frame.  In HTTP/3, when the GOAWAY frame is received by a client, it stops opening new streams even if the cumulative stream limit would allow. Instead the client would create a new connection on which to open further streams.  Once all streams are closed on the old connection, it can be terminated safely by a connection close or after expiration of the idle time out (see also sec-termination). </ins> 5.


length connection ID is also strongly recommended when migration is supported. <del> Currently QUIC only supports the use of a single network path at a time, which enables failover use cases.  Path validation is required so that endpoints validate paths before use to avoid address spoofing attacks.  Path validation takes at least one RTT and congestion control will also be reset after path migration.  Therefore migration usually has a performance impact. </del> <ins> The base specification of QUIC version 1 only supports the use of a single network path at a time, which enables failover use cases. Path validation is required so that endpoints validate paths before use to avoid address spoofing attacks.  Path validation takes at least one RTT and congestion control will also be reset after path migration.  Therefore migration usually has a performance impact. </ins> QUIC probing packets, which can be sent on multiple paths at once, are used to perform address validation as well as measure path


QUIC exposes some information to the network in the unencrypted part of the header, either before the encryption context is established or <del> because the information is intended to be used by the network.  QUIC has a long header that exposes some additional information (the version and the source connection ID), while the short header exposes only the destination connection ID.  In QUIC version 1, the long header is used during connection establishment, while the short header is used for data transmission in an established connection. </del> <ins> because the information is intended to be used by the network.  For more information on manageability of QUIC see also I-D.ietf-quic- manageability.  QUIC has a long header that exposes some additional information (the version and the source connection ID), while the short header exposes only the destination connection ID.  In QUIC version 1, the long header is used during connection establishment, while the short header is used for data transmission in an established connection. </ins> The connection ID can be zero length.  Zero length connection IDs can be chosen on each endpoint individually, on any packet except 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> Additionally, Application-Layer Version Negotiation RFC7301 permits the client and server to negotiate which of several protocols will be used on a given connection.  Therefore, multiple applications might be supported on a single UDP port based on the ALPN token offered. Applications using QUIC should register an ALPN token for use in the TLS handshake. Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example, HTTP/3 (Sections 3.2 and 3.3 of QUIC-HTTP) specifies the use of HTTP Alternative Services RFC7838 for an HTTP origin to advertise the availability of an equivalent HTTP/3 endpoint on a certain UDP port by using the "h3" ALPN token.  Note that HTTP/3's ALPN token ("h3") identifies not only the version of the application protocol, but also the version of QUIC itself; this approach allows unambiguous agreement between the endpoints on the protocol stack in use. </del> Given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of ports that cannot easily be mapped to a registered service name might


network elements such as firewalls that use the port number for application identification. <ins> Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example, HTTP/3 (Sections 3.2 and 3.3 of QUIC-HTTP) specifies the use of HTTP Alternative Services RFC7838 for an HTTP origin to advertise the availability of an equivalent HTTP/3 endpoint on a certain UDP port by using the "h3" Application-Layer Protocol Negotiation (ALPN) RFC7301 token. ALPN permits the client and server to negotiate which of several protocols will be used on a given connection.  Therefore, multiple applications might be supported on a single UDP port based on the ALPN token offered.  Applications using QUIC are required to register an ALPN token for use in the TLS handshake. As QUIC version 1 deferred defining a complete version negotiation mechanism, HTTP/3 requires QUIC version 1 and defines the ALPN token ("h3") to only apply to that version.  So far no single approach has been selected for managing the use of different QUIC versions, neither in HTTP/3 nor in general.  Application protocols that use QUIC need to consider how the protocol will manage different QUIC versions.  Decisions for those protocols might be informed by choices made by other protocols, like HTTP/3. </ins> 9. QUIC supports connection migration by the client.  If an IP address


5. <ins> As QUIC is a general purpose transport protocol, there are no requirements that servers use a particular UDP port for QUIC in general.  Instead, the same port number is used as would be used for the same application over TCP.  In the case of HTTP the expectation is that port 443 is used, which has already been registered for "http protocol over TLS/SSL".  However, QUIC-HTTP also specifies the use of Alt-Svc for HTTP/QUIC discovery which allows the server to use and announce a different port number. In general, port numbers serves two purposes: "first, they provide a demultiplexing identifier to differentiate transport sessions between the same pair of endpoints, and second, they may also identify the application protocol and associated service to which processes connect" RFC6335.  Note that the assumption that an application can be identified in the network based on the port number is less true today, due to encapsulation, mechanisms for dynamic port assignments as well as NATs. However, whenever a non-standard port is used which does not enable easy mapping to a registered service name, this can lead to blocking by network elements such as firewalls that rely on the port number as a first order of filtering. 6. </ins> [EDITOR'S NOTE: give some guidance here about the steps an application should take; however this is still work in progress] <del> 6. </del> <ins> 7. </ins> QUIC exposes some information to the network in the unencrypted part of the header, either before the encryption context is established,


Connection IDs), the short header exposes at most only a single Connection ID. <del> 6.1. </del> <ins> 7.1. </ins> QUIC supports a server-generated Connection ID, transmitted to the client during connection establishment (see Section 6.1 of QUIC).


The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption. <del> 6.2. </del> <ins> 7.2. </ins> While sufficiently robust connection ID generation schemes will mitigate linkability issues, they do not provide full protection.


migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means. <del> 6.3. </del> <ins> 7.3. </ins> QUIC provides a Server Retry packet that can be sent by a server in response to the Client Initial packet.  The server may choose a new


that the load balancer will redirect the next Client Initial packet to a different server in that pool. <del> 7. </del> <ins> 8. </ins> Versioning in QUIC may change the protocol's behavior completely, except for the meaning of a few header fields that have been declared


specification QUIC-TLS.  This split is performed to enable light- weight versioning with different cryptographic handshakes. <del> 8. </del> <ins> 9. </ins> This document has no actions for IANA. <del> 9. </del> <ins> 10. </ins> See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for


connection SHOULD fail to allow the application to explicitly handle fallback to a less-secure alternative.  See fallback. <del> 10. </del> <ins> 11. </ins> This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture


QUIC is an end-to-end transport protocol.  No information in the protocol header, even that which can be inspected, is mutable by the network.  This is achieved through integrity protection of the wire <del> image WIRE-IMAGE.  Encryption of most control signaling means that less information is visible to the network than is the case with TCP. </del> <ins> image WIRE-IMAGE.  Encryption of most transport-layer control signaling means that less information is visible to the network than is the case with TCP. </ins> Integrity protection can also simplify troubleshooting, because none of the nodes on the network path can modify transport layer


it describes what is and is not possible with the QUIC transport protocol as defined. <ins> This document focuses solely on network management practices that observe traffic on the wire.  Replacement of troubleshooting based on observation with active measurement techniques, for example, is therefore out of scope.  A more generalized treatment of network management operations on encrypted transports is given in RFC9065. </ins> QUIC-specific terminology used in this document is defined in QUIC- TRANSPORT.


2.4. New QUIC connections are established using a handshake, which is <del> distinguishable on the wire and contains some information that can be passively observed. </del> <ins> distinguishable on the wire (see sec-identifying for details), and contains some information that can be passively observed. </ins> To illustrate the information visible in the QUIC wire image during the handshake, we first show the general communication pattern


The client's TLS ClientHello may contain a Server Name Indication (SNI) RFC6066 extension, by which the client reveals the name of the server it intends to connect to, in order to allow the server to <del> present a certificate based on that name.  It may also contain an Application-Layer Protocol Negotiation (ALPN) RFC7301 extension, by which the client exposes the names of application-layer protocols it supports; an observer can deduce that one of those protocols will be used if the connection continues. </del> <ins> present a certificate based on that name.  SNI information is available to unidirectional observers on the client-to-server path, if present. The TLS ClientHello may also contain an Application-Layer Protocol Negotiation (ALPN) RFC7301 extension, by which the client exposes the names of application-layer protocols it supports; an observer can deduce that one of those protocols will be used if the connection continues. </ins> Work is currently underway in the TLS working group to encrypt the contents of the ClientHello in TLS 1.3 TLS-ECH.  This would make SNI-


recognition of the handshake, as illustrated in handshake.  It can also be inferred during the flow's lifetime, if the endpoints use the spin bit facility described below and in Section 17.3.1 of QUIC- <del> TRANSPORT. </del> <ins> TRANSPORT.  RTT measurement is available to unidirectional observers when the spin bit is enabled. </ins> 3.8.1.


for other control processes, and a short header that may be used for data transmission in an established connection.  While the long header always exposes some information (such as the version and <del> Connection IDs), the short header only optionally exposes a single Connection ID. Given that exposing this information may make it possible to associate multiple addresses with a single client during rebinding, which has privacy implications, an application may indicate to not support exposure of certain information after the handshake. Specifically, an application that has additional information that the client is not behind a NAT and the server is not behind a load balancer, and therefore it is unlikely that the addresses will be re- bound, may indicate to the transport that is wishes to not expose a </del> <ins> Connection IDs), the short header exposes at most only a single </ins> Connection ID. 6.1. QUIC supports a server-generated Connection ID, transmitted to the client during connection establishment (see Section 6.1 of QUIC). <del> Servers behind load balancers should propose a Connection ID during the handshake, encoding the identity of the server or information about its load balancing pool, in order to support stateless load balancing.  Once the server generates a Connection ID that encodes its identity, every CDN load balancer would be able to forward the packets to that server without needing information about every specific flow it is forwarding. Server-generated Connection IDs must not encode any information other that that needed to route packets to the appropriate backend server(s): typically the identity of the backend server or pool of servers, if the data-center's load balancing system keeps "local" state of all flows itself.  Care must be exercised to ensure that the information encoded in the Connection ID is not sufficient to identify unique end users.  Note that by encoding routing information in the Connection ID, load balancers open up a new attack vector that allows bad actors to direct traffic at a specific backend server or pool.  It is therefore recommended that Server-Generated Connection ID includes a cryptographic MAC that the load balancer pool server is able to identify and discard packets featuring an invalid MAC. </del> <ins> Servers behind load balancers may need to propose a Connection ID during the handshake, encoding the identity of the server or information about its load balancing pool, in order to support stateless load balancing.  Once the server generates a Connection ID that encodes its identity, every CDN load balancer would be able to forward the packets to that server without retaining connection state. Server-generated connection IDs should seek to obscure any encoding, of routing identities or any other information.  Exposing the server mapping would allow linkage of multiple IP addresses to the same host if the server also supports migration.  Furthermore, this opens an attack vector on specific servers or pools. The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption. </ins> 6.2. <ins> While sufficiently robust connection ID generation schemes will mitigate linkability issues, they do not provide full protection. Analysis of the lifetimes of six-tuples (source and destination addresses as well as the migrated CID) may expose these links anyway. In the limit where connection migration in a server pool is rare, it is trivial for an observer to associate two connection IDs. Conversely, in the opposite limit where every server handles multiple simultaneous migrations, even an exposed server mapping may be insufficient information. The most efficient mitigation for these attacks is operational, either by using a load balancing architecture that loads more flows onto a single server-side address, by coordinating the timing of migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means. 6.3. </ins> QUIC provides a Server Retry packet that can be sent by a server in response to the Client Initial packet.  The server may choose a new Connection ID in that packet and the client will retry by sending


that the load balancer will redirect the next Client Initial packet to a different server in that pool. <del> 6.3. QUIC provides for multiple Server and Client Connection IDs to be used simultaneously by a given connection, which allows seamless connection migration when one of the endpoints changes IP address and/or UDP port.  Section 6.11.5 of QUIC describes how to use this facility to reduce the risk of exposing a link among these addresses to observers on the network.  However, analysis of the lifetimes of six-tuples (source and destination addresses as well as the migrated CID) may expose these links anyway. In practice, a finite set of flows will be undergoing migration within any one time window as seen from any given observation point in the network, and any migration must keep at least one endpoint address constant during the migration.  Because of this, a key insight here is that this finite set of flows represents the anonymity set for any one flow undergoing migration within it.  For endpoints with low volume, this anonymity set will be necessarily small, so there remains a significant risk of linkage exposure through timing-based analysis. The most efficient mitigation for these attacks is operational, by increasing the size of the anonymity set as seen from a passive observer in the Internet, either by using a load balancing architecture that loads more flows onto a single server-side address, by coordinating the timing of migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means. </del> 7. Versioning in QUIC may change the protocol's behavior completely,


semantics as needed for HTTP/2 QUIC-HTTP.  Based on current deployment practices, QUIC is encapsulated in UDP and encrypted by default.  The current version of QUIC integrates TLS QUIC-TLS to <del> encrypt all payload data and most control information.  Given QUIC is an end-to-end transport protocol, all information in the protocol header, even that which can be inspected, is is not meant to be mutable by the network, and is therefore integrity-protected to the extent possible. </del> <ins> encrypt all payload data and most control information. Given that QUIC is an end-to-end transport protocol, all information in the protocol header, even that which can be inspected, is not meant to be mutable by the network, and is therefore integrity- protected.  While less information is visible to the network than for TCP, integrity protection can also simplify troubleshooting because none of the nodes on the network path can modify the transport layer information. </ins> This document provides guidance for network operation on the management of QUIC traffic.  This includes guidance on how to


3.1. <del> [EDITOR'S NOTE: Jana noted at the interim in Paris that we should point out that applications need to be re-thought slightly to get the benefits of zero RTT.  Add a little text here to discuss this and why it's worth the effort, before we go straight into the dragons.] </del> <ins> A transport protocol that provides 0-RTT connection establishment to recently contacted servers is qualitatively different than one that does not from the point of view of the application using it. Relative tradeoffs between the cost of closing and reopening a connection and trying to keep it open are different; see resumption- v-keepalive. Applications must be slightly rethought in order to make best use of 0-RTT resumption.  Most importantly, application operations must be divided into idempotent and non-idempotent operations, as only idempotent operations may appear in 0-RTT packets.  This implies that the interface between the application and transport layer exposes idempotence either ecplicitly or implicitly. </ins> 3.2. <del> However, data in the frames contained in 0-RTT packets of a such a connection must be treated specially by the application layer. Replay of these packets can cause the data to processed twice.  This is further described in HTTP-RETRY. 0-RTT data also does not benefit from perfect forward secrecy (PFS). Applications that cannot treat data that may appear in a 0-RTT connection establishment as idempotent MUST NOT use 0-RTT establishment.  For this reason the QUIC transport SHOULD provide an interface for the application to indicate if 0-RTT support is in general desired or a way to indicate whether data is idempotent, and/ or whether PFS is a hard requirement </del> <ins> Retransmission or (malicious) replay of data contained in 0-RTT resumption packets could cause the server side to receive two copies of the same data.  This is further described in HTTP-RETRY.  Data sent during 0-RTT resumption also cannot benefit from perfect forward secrecy (PFS). Data in the first flight sent by the client in a connection established with 0-RTT MUST be idempotent.  Applications MUST be designed, and their data MUST be framed, such that multiple reception of idempotent data is recognized as such by the receiverApplications that cannot treat data that may appear in a 0-RTT connection establishment as idempotent MUST NOT use 0-RTT establishment.  For this reason the QUIC transport SHOULD provide an interface for the application to indicate if 0-RTT support is in general desired or a way to indicate whether data is idempotent, and/or whether PFS is a hard requirement for the application. </ins> 3.3. <del> [EDITOR'S NOTE: guidance/recommendation to us 0-RTT session resumption rather then sending keep-alives?] </del> <ins> [EDITOR'S NOTE: see https://github.com/quicwg/ops-drafts/issues/6] </ins> 4.


<del> Combining EDHOC and OSCORE </del> <ins> Using EDHOC for OSCORE with CoAP Transport </ins> draft-ietf-core-oscore-edhoc-latest Abstract <del> This document defines an optimization approach for combining the lightweight authenticated key exchange protocol EDHOC run over CoAP with the first subsequent OSCORE transaction.  This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. </del> <ins> This document defines how the lightweight authenticated key exchange protocol EDHOC is used for establishing an OSCORE Security Context, using CoAP for message transferring.  Furthermore, this document defines an optimization approach for combining EDHOC run over CoAP with the first subsequent OSCORE transaction.  This reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. </ins> 1. <del> This document defines an optimization approach to combine the lightweight authenticated key exchange protocol EDHOC I-D.ietf-lake- edhoc, when running over CoAP RFC7252, with the first subsequent OSCORE RFC8613 transaction. </del> <ins> Ephemeral Diffie-Hellman Over COSE (EDHOC) I-D.ietf-lake-edhoc is a lightweight authenticated key exchange protocol, especially intended for use in constrained scenarios.  As defined in Section 7.2 of I- D.ietf-lake-edhoc, EDHOC messages can be transported over the Constrained Application Protocol (CoAP) RFC7252. </ins> <del> This allows for a minimum number of round trips necessary to setup the OSCORE Security Context and complete an OSCORE transaction, for example when an IoT device gets configured in a network for the first time. </del> <ins> This document builds on the EDHOC specification I-D.ietf-lake-edhoc and defines how EDHOC run over CoAP is used for establishing a Security Context for Object Security for Constrained RESTful Environments (OSCORE) RFC8613. In addition, this document defines an optimization approach that combines EDHOC run over CoAP with the first subsequent OSCORE transaction.  This allows for a minimum number of round trips necessary to setup the OSCORE Security Context and complete an OSCORE transaction, for example, when an IoT device gets configured in a network for the first time. </ins> This optimization is desirable, since the number of protocol round trips impacts the minimum number of flights, which in turn can have a


Without this optimization, it is not possible, not even in theory, to achieve the minimum number of flights.  This optimization makes it <del> possible also in practice, since the last message of the EDHOC </del> <ins> possible also in practice since the last message of the EDHOC </ins> protocol can be made relatively small (see Section 1 of I-D.ietf- lake-edhoc), thus allowing additional OSCORE protected CoAP data within target MTU sizes.


2. <del> EDHOC is a 3-message key exchange protocol.  Section 7.2 of I-D.ietf- lake-edhoc specifies how to transport EDHOC over CoAP: the EDHOC data (referred to as "EDHOC messages") are transported in the payload of CoAP requests and responses. </del> <ins> The EDHOC protocol allows two peers to agree on a cryptographic secret, in a mutually-authenticated way and by using Diffie-Hellman ephemeral keys to achieve perfect forward secrecy.  The two peers are denoted as Initiator and Responder, as the one sending or receiving the initial EDHOC message_1, respectively. After successful processing of EDHOC message_3, both peers agree on a cryptographic secret that can be used to derive further security material, and especially to establish an OSCORE Security Context RFC8613.  The Responder can also send an optional EDHOC message_4 to achieve key confirmation, e.g. in deployments where no protected application message is sent from the Responder to the Initiator. Section 7.2 of I-D.ietf-lake-edhoc specifies how to transport EDHOC over CoAP.  That is, the EDHOC data (referred to as "EDHOC messages") are transported in the payload of CoAP requests and responses.  The default message flow consists in the CoAP Client acting as Initiator and the CoAP Server acting as Responder.  Alternatively, the two roles can be reversed.  In the rest of this document, EDHOC messages are considered to be transported over CoAP. fig-non-combined shows a Client and Server running EDHOC as Initiator and Responder, respectively.  That is, the Client sends a POST request with payload EDHOC message_1 to a reserved resource at the CoAP Server, by default at Uri-Path "/.well-known/edhoc".  This triggers the EDHOC exchange at the Server, which replies with a 2.04 (Changed) Response with payload EDHOC message_2.  Finally, the Client sends a CoAP POST request to the same resource used for EDHOC message_1, with payload EDHOC message_3.  The Content-Format of these CoAP messages may be set to "application/edhoc". After this exchange takes place, and after successful verifications as specified in the EDHOC protocol, the Client and Server can derive an OSCORE Security Context, as defined in oscore-ctx of this document.  After that, they can use OSCORE to protect their communications. </ins> <del> This draft deals with the case of the Initiator acting as CoAP Client and the Responder acting as CoAP Server; instead, the case of the Initiator acting as CoAP Server cannot be optimized by using this approach. </del> <ins> As shown in fig-non-combined, this purely-sequential way of first running EDHOC and then using OSCORE takes three round trips to complete. </ins> <del> That is, the CoAP Client sends a POST request containing EDHOC message_1 to a reserved resource at the CoAP Server.  This triggers the EDHOC exchange on the CoAP Server, which replies with a 2.04 (Changed) Response containing EDHOC message_2.  Finally, the CoAP Client sends EDHOC message_3, as a CoAP POST request to the same resource used for EDHOC message_1.  The Content-Format of these CoAP messages may be set to "application/edhoc". </del> <ins> edhoc-in-oscore defines an optimization for combining EDHOC with the first subsequent OSCORE transaction.  This reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. </ins> <del> After this exchange takes place, and after successful verifications specified in the EDHOC protocol, the Client and Server derive the OSCORE Security Context, as specified in Section 7.2.1 of I-D.ietf- lake-edhoc.  Then, they are ready to use OSCORE. </del> <ins> 3. </ins> <del> This sequential way of running EDHOC and then OSCORE is specified in fig-non-combined.  As shown in the figure, this mechanism takes 3 round trips to complete. </del> <ins> When using EDHOC over CoAP for establishing an OSCORE Security Context, EDHOC messages are exchanged as defined in Section 7.2 of I- D.ietf-lake-edhoc, with the following addition. </ins> <del> The number of roundtrips can be minimized as follows.  Already after receiving EDHOC message_2 and before sending EDHOC message_3, the CoAP Client has all the information needed to derive the OSCORE Security Context. </del> <ins> EDHOC error messages sent as CoAP responses MUST be error responses, i.e. they MUST specify a CoAP error response code.  In particular, it is RECOMMENDED that such error responses have response code either 4.00 (Bad Request) in case of client error (e.g. due to a malformed EDHOC message), or 5.00 (Internal Server Error) in case of server error (e.g. due to failure in deriving EDHOC key material). </ins> <del> This means that the Client can potentially send at the same time both EDHOC message_3 and the subsequent OSCORE Request.  On a semantic level, this approach practically requires to send two separate REST requests at the same time. </del> <ins> 4. </ins> <del> The high level message flow of running EDHOC and OSCORE combined is shown in fig-combined. </del> <ins> After successful processing of EDHOC message_3 (see Section 5.5 of I- D.ietf-lake-edhoc), the Client and Server derive Security Context parameters for OSCORE (see Section 3.2 of RFC8613) as follows. The Master Secret and Master Salt are derived by using the EDHOC- Exporter interface defined in Section 4.1 of I-D.ietf-lake-edhoc. The EDHOC Exporter Labels to use are "OSCORE Master Secret" and "OSCORE Master Salt", for deriving the OSCORE Master Secret and the OSCORE Master Salt, respectively. By default, key_length is the key length (in bytes) of the application AEAD Algorithm of the selected cipher suite for the EDHOC session.  Also by default, salt_length has value 8.  The Initiator and Responder MAY agree out-of-band on a longer key_length than the default and on a different salt_length. The AEAD Algorithm is the application AEAD algorithm of the selected cipher suite for the EDHOC session. The HKDF Algorithm is the HKDF algorithm of the selected cipher suite for the EDHOC session. In case the Client is the Initiator and the Server is the Responder, the Client's OSCORE Sender ID and the Server's OSCORE Sender ID are the byte string EDHOC connection identifier C_R and C_I for the EDHOC session, respectively.  The reverse applies in case the Client is the Responder and the Server is the Initiator. Numeric connection identifiers are converted to (naturally byte- string shaped) Sender IDs by using their CBOR encoded form.  For example, a C_R of 10 corresponds to a (typically server) Sender ID of hexadecimal '0a', -12 to hexadecimal '2b', whereas a byte- string valued C_R of h'ff' corresponds to a Sender ID of hexadecimal 'ff'. Before deriving an OSCORE Security Context, the two peers MUST ensure that the EDHOC connection identifiers are different. that is, the two peers MUST NOT derive an OSCORE Security Context from an EDHOC session, if C_R is equal to C_I for that session. If the Responder runs EDHOC with the intention of deriving an OSCORE Security Context, the Responder MUST NOT include in EDHOC message_2 a connection identifier C_R equivalent (under conversion to a Sender ID) to the connection identifier C_I received in EDHOC message_1.  If the Initiator runs EDHOC with the intention of deriving an OSCORE Security Context, the initiator MUST discontinue the protocol and reply with an EDHOC error message when receiving an EDHOC message_2 that includes a connection identifier C_R equal to C_I. The Client and Server use the parameters above to establish an OSCORE Security Context, as per Section 3.2.1 of RFC8613. From then on, the Client and Server MUST be able to retrieve the OSCORE protocol state using its chosen connection identifier, and optionally other information such as the 5-tuple, i.e., the tuple (source IP address, source port, destination IP address, destination port, transport protocol). </ins> <del> Defining the specific details of how to transport the data and of their processing order is the goal of this specification, as defined in edhoc-in-oscore. </del> <ins> 5. </ins> <del> 3. </del> <ins> This section defines an optimization for combining the EDHOC exchange with the first subsequent OSCORE transaction, thus minimizing the number of round trips between the two peers. This approach can be used only if the default EDHOC message flow is used, i.e., when the Client acts as Initiator and the Server acts as Responder, while it cannot be used in the case with reversed roles. When running the purely-sequential flow of overview, the Client has all the information to derive the OSCORE Security Context already after receiving EDHOC message_2 and before sending EDHOC message_3. Hence, the Client can potentially send both EDHOC message_3 and the subsequent OSCORE Request at the same time.  On a semantic level, this requires sending two REST requests at once, as in fig-combined. To this end, the specific approach defined in this section consists of sending EDHOC message_3 inside an OSCORE protected CoAP message. The resulting EDHOC + OSCORE request is in practice the OSCORE Request from fig-non-combined, as still sent to a protected resource and with the correct CoAP method and options, but with the addition that it also transports EDHOC message_3. As EDHOC message_3 may be too large to be included in a CoAP Option, e.g., if containing a large public key certificate chain, it has to be transported in the CoAP payload of the EDHOC + OSCORE request. The rest of this section specifies how to transport the data in the EDHOC + OSCORE request and their processing order.  In particular, the use of this approach is explicitly signalled by including an EDHOC Option (see edhoc-option) in the EDHOC + OSCORE request.  The processing of the EDHOC + OSCORE request is specified in client- processing for the Client side and in server-processing for the Server side. </ins> <del> This section defines the EDHOC Option, used in a CoAP request to signal that the request combines EDHOC message_3 and OSCORE protected data. </del> <ins> 5.1. This section defines the EDHOC Option.  The option is used in a CoAP request, to signal that the request payload conveys both an EDHOC message_3 and OSCORE protected data, combined together. </ins> The EDHOC Option has the properties summarized in fig-edhoc-option, which extends Table 4 of RFC7252.  The option is Critical, Safe-to-


EDHOC data and the OSCORE ciphertext, using the newly defined EDHOC option for signalling. <del> 4. The approach defined in this specification consists of sending EDHOC message_3 inside an OSCORE protected CoAP message. The resulting EDHOC + OSCORE request is in practice the OSCORE Request from fig-non-combined, sent to a protected resource and with the correct CoAP method and options, with the addition that it also transports EDHOC message_3. Since EDHOC message_3 may be too large to be included in a CoAP Option, e.g. if containing a large public key certificate chain, it has to be transported through the CoAP payload. The use of this approach is explicitly signalled by including an EDHOC Option (see signalling) in the EDHOC + OSCORE request. 4.1. </del> <ins> 5.2. </ins> The Client prepares an EDHOC + OSCORE request as follows.


the CBOR sequence built at step 3. Signal the usage of this approach within the EDHOC + OSCORE <del> request, by including the new EDHOC Option defined in signalling. </del> <ins> request, by including the new EDHOC Option defined in edhoc- option. </ins> <del> 4.2. </del> <ins> 5.3. </ins> <del> When receiving an EDHOC + OSCORE request, the Server performs the following steps. </del> <ins> When receiving a request containing the EDHOC option, i.e. an EDHOC + OSCORE request, the Server MUST perform the following steps. </ins> <del> Check the presence of the EDHOC option defined in signalling, to determine that the received request is an EDHOC + OSCORE request. If this is the case, the Server continues with the steps defined below. </del> <ins> Check that the payload of the EDHOC + OSCORE request is a CBOR sequence composed of two CBOR byte strings.  If this is not the case, the Server MUST stop processing the request and MUST respond with a 4.00 (Bad Request) error message. </ins> Extract CIPHERTEXT_3 from the payload of the EDHOC + OSCORE request, as the first CBOR byte string in the CBOR sequence.


derivation, as per Section 5.4.3 and Section 7.2.1 of I-D.ietf- lake-edhoc, respectively. <ins> If the applicability statement used in the EDHOC session specifies that EDHOC message_4 shall be sent, the Server MUST stop the EDHOC processing and consider it failed, as due to a client error. </ins> Extract the OSCORE ciphertext from the payload of the EDHOC + OSCORE request, as the value of the second CBOR byte string in the CBOR sequence.


is not applicable to the approach defined in this specification. If step 4 (EDHOC processing) fails, the server discontinues the <del> protocol as per Section 5.4.3 of I-D.ietf-lake-edhoc and sends an EDHOC error message, formatted as defined in Section 6.1 of I-D.ietf- lake-edhoc.  In particular, the CoAP response conveying the EDHOC error message: MUST have Content-Format set to application/edhoc defined in Section 9.5 of I-D.ietf-lake-edhoc. MUST specify a CoAP error response code, i.e. 4.00 (Bad Request) in case of client error (e.g. due to a malformed EDHOC message_3), or 5.00 (Internal Server Error) in case of server error (e.g. due to failure in deriving EDHOC key material). </del> <ins> protocol as per Section 5.4.3 of I-D.ietf-lake-edhoc and responds with an EDHOC error message, formatted as defined in Section 6.1 of I-D.ietf-lake-edhoc.  In particular, the CoAP response conveying the EDHOC error message MUST have Content-Format set to application/edhoc defined in Section 9.5 of I-D.ietf-lake-edhoc. </ins> If step 4 (EDHOC processing) is successfully completed but step 7 (OSCORE processing) fails, the same OSCORE error handling applies as defined in Section 8.2 of RFC8613. <del> 5. </del> <ins> 5.4. </ins> <del> An example based on the OSCORE test vector from Appendix C.4 of RFC8613 and the EDHOC test vector from Appendix B.2 of I-D.ietf-lake- edhoc is given in fig-edhoc-opt-2.  In particular, the example assumes that: </del> <ins> fig-edhoc-opt-2 shows an example of EDHOC + OSCORE Request, based on the OSCORE test vector from Appendix C.4 of RFC8613 and the EDHOC test vector from Appendix B.2 of I-D.ietf-lake-edhoc.  In particular, the example assumes that: </ins> The used OSCORE Partial IV is 0, consistently with the first request protected with the new OSCORE Security Context. <del> The OSCORE Sender ID of the Client is 0x20.  This corresponds to </del> <ins> The OSCORE Sender ID of the Client is 0x00.  This corresponds to </ins> the EDHOC Connection Identifier C_R, which is encoded as the <del> bstr_identifier 0x08 in EDHOC message_3. </del> <ins> bstr_identifier 0x37 in EDHOC message_3. </ins> <del> The EDHOC option is registered with CoAP option number 13. </del> <ins> The EDHOC option is registered with CoAP option number 21. </ins> 6.


7. <ins> RFC Editor: Please replace "[[this Document]]" with the RFC number of this document and delete this paragraph. </ins> This document has the following actions for IANA. 7.1.


[ The CoAP option numbers 13 and 21 are both consistent with the <del> properties of the EDHOC Option defined in signalling, and they both </del> <ins> properties of the EDHOC Option defined in edhoc-option, and they both </ins> allow the EDHOC Option to always result in an overall size of 1 byte. This is because:


unassigned in the "CoAP Option Numbers" registry, as first available and consistent option numbers for the EDHOC option. <ins> This document suggests 21 (TBD21) as option number to be assigned to the new EDHOC option, since both 13 and 21 are consistent for the use case in question, but different use cases or protocols may make better use of the option number 13. </ins> ] <ins> 7.2. IANA is asked to enter the following entries to the "EDHOC Exporter Label" registry defined in I-D.ietf-lake-edhoc. </ins>