the order of notifications, the client SHALL maintain a Notification Number for each Observation it registers.  The Notification Number is a non-negative integer containing the largest Partial IV of the <del> received notifications for the associated Observe registration (see replay-protection).  The Notification Number is initialized to the Partial IV of the first successfully received notification response to the registration request.  In contrast to RFC7641, the received Partial IV MUST always be compared with the Notification Number, which thus MUST NOT be forgotten after 128 seconds.  Further details of replay protection of notifications are specified in replay- protection. Clients can re-register observations to ensure that the observation is still active and establish freshness again (RFC7641 Section 3.3.1).  When an OSCORE protected observation is refreshed, not only the ETags, but also the partial IV (and thus the payload and OSCORE option) change.  The server uses the new request's Partial IV as the 'request_piv' of new responses. </del> <ins> received notifications for the associated Observe registration. Further details of replay protection of notifications are specified in replay-notifications. The Inner Observe in a response MUST either have the value of Observe in the original CoAP message or be empty.  The former is used to allow the server to set the Observe values to be received by the client.  In the latter case the overhead of the Observe value is saved and instead the least significant bytes of the Partial IV is used as Observe value, see replay-notifications.  The Outer Observe in the response may be needed for intermediary nodes to support multiple responses to one request.  The client MAY ignore the Outer Observe value. If the client receives a response to an Observe request without an Observe value, then it verifies the response as a non-Observe response, as specified in ver-res.  If the client receives a response to a non-Observe request with an Observe value, then it stops processing the message but keeps the observation alive, as specified in ver-res. </ins> 4.1.3.5.


The sending endpoint SHALL write the Code of the original CoAP message into the plaintext of the COSE object (see plaintext).  After that, the sending endpoint writes an Outer Code to the OSCORE <del> message.  With one exeception (see observe-option-processing) the Outer Code SHALL by default be set to 0.02 (POST) for requests and to 2.04 (Changed) for responses.  The receiving endpoint SHALL discard the Outer Code in the OSCORE message and write the Code of the COSE object plaintext (plaintext) into the decrypted CoAP message. </del> <ins> message.  With one exeception (see observe) the Outer Code SHALL by default be set to 0.02 (POST) for requests and to 2.04 (Changed) for responses.  The receiving endpoint SHALL discard the Outer Code in the OSCORE message and write the Code of the COSE object plaintext (plaintext) into the decrypted CoAP message. </ins> The other currently defined CoAP Header fields are Unprotected (Class U).  The sending endpoint SHALL write all other header fields of the


7.4.1. <del> Additionally to the previous section, the following applies when Observe is supported. 7.4.1.1. A client receiving a notification SHALL compare the Partial IV of a received notification with the Notification Number associated to that Observe registration.  The ordering of notifications after OSCORE processing MUST be aligned with the Partial IV.  The client MAY do so by copying the least significant bytes of the Partial IV into the Observe option, before passing it to CoAP processing.  The client MAY ignore an Outer Observe option value.  If the verification of the response succeeds, and the received Partial IV was greater than the Notification Number, then the client SHALL update the corresponding Notification Number with the received Partial IV.  The client MUST stop processing notifications with a Partial IV which has been previously received.  An application MAY require the client to discard notifications which have Partial IV less than the Notification Number. If messages are processed concurrently, the Partial IV needs to be validated a second time after decryption and before updating the replay protection data.  The operation of validating the Partial IV and updating the replay protection data MUST be atomic. 7.4.1.2. In order to allow intermediaries to re-register their interest in a resource (see 3.3.1 of RFC7641), a server receiving an Observe registration with Token, kid and Partial IV identical to a previously received registration, and which decrypts without error SHALL not treat it as a replay and SHALL respond with a notification.  The notification may be a cached copy of the latest sent notification (with the same Token, kid and Partial IV) or it may be a newly generated notification with a fresh Partial IV. </del> <ins> The following applies additionally when Observe is supported. The Notification Number is initialized to the Partial IV of the first successfully received notification response to the registration request.  A client receiving a notification SHALL compare the Partial IV of a verified notification with the Notification Number associated to that Observe registration.  In contrast to RFC7641, the received Partial IV MUST always be compared with the Notification Number, which thus MUST NOT be forgotten after 128 seconds. If the verification of the response succeeds, and the received Partial IV was greater than the Notification Number, then the client SHALL update the corresponding Notification Number with the received Partial IV.  The operation of validating the Partial IV and updating the replay protection data MUST be atomic.  If the Inner Observe option is empty, then the client SHALL copy the least significant bytes of the Partial IV into the Observe option, before passing it to CoAP processing. If the Partial IV is less than or equal to the Notification Number, then the client SHALL stop processing the response but not cancel the observation. </ins> 7.5.


7.5.3. <del> To prevent accepting replay of previously received notification responses, the client may perform the following procedure after boot: </del> <ins> To prevent accepting replay of previously received notifications, the client may perform the following procedure after boot: </ins> <del> The client rejects notifications bound to the earlier registration, removes all Notification Numbers and re-registers using Observe. </del> <ins> The client forgets about earlier registrations, removes all Notification Numbers and re-registers using Observe. </ins> 8.


If Observe is implemented: <del> Replace step 1 in ver-req with: A.  Discard Code and all options marked in fig-option-protection with 'x' in column E, except for Observe, present in the received message. For example, an If-Match Outer option is discarded, Uri-Host Outer option is not discarded, Observe is not discarded. </del> <ins> Insert the following step before step 1 in ver-req: </ins> <del> Replace step 3 in ver-req with: </del> <ins> A.  Check if the Outer Observe option is present and has value zero. </ins> <del> B.  If Observe is present in the received message, and has value 0, check if the Token, kid and Partial IV are identical to a previously received Observe registration.  In this case, replay verification is postponed until step C.  Otherwise verify the 'Partial IV' parameter using the Replay Window, as described in replay-protection. </del> <ins> Insert the following step between step 6 and 7 of ver-req: </ins> <del> Insert the following steps between step 6 and 7 of ver-req: C.  If Observe was present in the received message (in step 1): If the value of Observe in the Outer message is 0: If Observe is present and has value 0 in the decrypted options, discard the Outer Observe.  If the Token, kid and Partial IV are identical to a previously received Observe registration, respond with a notification as described in observe-replay- processing; Otherwise, discard both the Outer and Inner (if present) Observe options and verify the 'Partial IV' parameter using the Replay Window, as described in replay-protection. If the value of Observe in the Outer message is not 0, discard the decrypted Observe option if present. </del> <ins> B.  If Inner Observe is present and has value zero, and Outer option is either not present or has not value 0, then remove the Observe option. </ins> 8.3.


If Observe is implemented: <del> Replace step 1 of ver-res with: A.  Discard Code and all options marked in fig-option-protection with 'x' in column E, except for Observe, present in the received message. For example, ETag Outer option is discarded, as well as Max-Age Outer option, Observe is not discarded. Insert the following steps between step 2 and 3 of ver-res: B.  If the Observe option is present in the response, but the request was not an Observe registration, then go to 9. </del> <ins> Replace step 6 of ver-res with: </ins> <del> C.  If an Observe option is included or the Notification number for the observation has already been initiated, but the Partial IV is not present in the response, then go to 9. </del> <ins> A.  If Inner Observe is present then: </ins> <del> D.  For Observe notifications, verify the received 'Partial IV' parameter against the corresponding Notification Number as described in replay-protection. </del> <ins> If the request was not an Observe registration, then go to 9. </ins> <del> Replace step 6 of ver-res with: </del> <ins> If the Partial IV was not present in the response, then go to 9. </ins> <del> E.  If the response is a notification, initiate or update the corresponding Notification Number, as described in sequence-numbers. Otherwise, delete the attribute-value pair (Token, {Security Context, PIV}). </del> <ins> If the request was an Observe registration and the Partial IV was present in the response, then verify the received 'Partial IV' parameter against the corresponding Notification Number, and follow the processing described in replay-notifications. Otherwise, delete the attribute-value pair (Token, {Security Context, PIV}). </ins> <del> Replace step 7 of ver-res with: </del> <ins> Replace step 9 of ver-res with: </ins> <del> F.  Add decrypted Code, options and payload to the decrypted request, except for decrypted Observe if present.  The OSCORE option is removed. </del> <ins> B.  In case any of the previous erroneous conditions apply: the client SHALL stop processing the response.  An error condition occurring while processing a response in an observation does not cancel the observation.  A client MUST NOT react to failure by re- registering the observation immediately. </ins> <del> An error condition occurring while processing a response in an observation does not cancel the observation.  A client MUST NOT react to failure in step 5 by re-registering the observation immediately. </del> <ins> Note that the attribute-value attribute-value pair (Token, {Security Context, PIV}) MUST be deleted whenever the Observation is cancelled or "forgotten". </ins> 9.


receiving endpoint discards the message, if complying to the policy) may be obtained as part of normal resource discovery. <ins> Applications need to use a padding scheme if the content of a message can be determined solely from the length of the payload.  As an example, the strings "YES" and "NO" even if encrypted can be distinguished from each other as there is no padding supplied by the current set of encryption algorithms.  Some information can be determined even from looking at boundary conditions.  An example of this would be returning an integer between 0 and 100 where lengths of 1, 2 and 3 will provide information about where in the range things are.  Three different methods to deal with this are: 1) ensure that all messages are the same length.  For example using 0 and 1 instead of 'yes' and 'no'.  2) Use a character which is not part of the responses to pad to a fixed length.  For example, pad with a space to three characters.  3) Use the PKCS #7 style padding scheme where m bytes are appended each having the value of m.  For example, appending a 0 to "YES" and two 1's to "NO".  This style of padding means that all values need to be padded. </ins> 8. Privacy threats executed through intermediate nodes are considerably


Distributor, this framework utilizes a DTLS-SRTP RFC5764 association between an endpoint and the Key Distributor.  To establish this association, an endpoint will send DTLS-SRTP messages to the Media <del> Distributor which will then forward them to the Media Distributor as </del> <ins> Distributor which will then forward them to the Key Distributor as </ins> defined in I-D.jones-perc-dtls-tunnel.  The Key Encryption Key (KEK) (i.e., EKT Key) is also conveyed by the Key Distributor over the DTLS association to endpoints via procedures defined in PERC EKT [I-


Media Distributors use DTLS-SRTP RFC5764 directly with a peer Media Distributor to establish HBH keys for transmitting RTP and RTCP <del> packets that peer Media Distributor.  The Key Distributor does not </del> <ins> packets to that peer Media Distributor.  The Key Distributor does not </ins> facilitate establishing HBH keys for use between Media Distributors. 4.5.1. The procedures defined in DTLS Tunnel for PERC I-D.jones-perc-dtls- <del> tunnel establish one or more DTLS tunnels between the Media </del> <ins> tunnel establish one or more TLS tunnels between the Media </ins> Distributor and Key Distributor, making it is possible for the Media Distributor to facilitate the establishment of a secure DTLS association between each endpoint and the Key Distributor as shown


the DTLS signaling, but will instead forward DTLS packets received from an endpoint on to the Key Distributor (and vice versa) via a tunnel established between Media Distributor and the Key Distributor. <del> This tunnel used to encapsulate the DTLS-SRTP signaling between the Key Distributor and endpoints will also be used to convey HBH key </del> <ins> This tunnel is used to encapsulate the DTLS-SRTP signaling between the Key Distributor and endpoints will also be used to convey HBH key </ins> information from the Key Distributor to the Media Distributor, so no additional protocol or interface is required.


fingerprint of the DTLS-SRTP certificate used for the call.  This certificate is unique for a given call and a conference.  This allows the Key Distributor to ensure that only authorized users participate <del> in the conference.  Similarly the Key Distributor can create a WeBRTC Identity assertion bound the fingerprint of the unique certificate </del> <ins> in the conference.  Similarly the Key Distributor can create a WebRTC Identity assertion to bind the fingerprint of the unique certificate </ins> used by the Key Distributor for this conference so that the endpoint can validate it is talking to the correct Key Distributor.


This document defines an extension to DTLS-SRTP called SRTP EKT Key Transport which enables secure transport of EKT keying material from <del> one DTLS-SRTP peer to another.  This allows those peers to process EKT keying material in SRTP (or SRTCP) and retrieve the embedded SRTP keying material.  This combination of protocols is valuable because it combines the advantages of DTLS, which has strong authentication of the endpoint and flexibility, along with allowing secure multiparty RTP with loose coordination and efficient communication of per-source keys. </del> <ins> the DTLS-SRTP peer in the server role to the client.  This allows those peers to process EKT keying material in SRTP (or SRTCP) and retrieve the embedded SRTP keying material.  This combination of protocols is valuable because it combines the advantages of DTLS, which has strong authentication of the endpoint and flexibility, along with allowing secure multiparty RTP with loose coordination and efficient communication of per-source keys. </ins> 5.1.


5.2. <del> This document defines a new TLS negotiated extension called "srtp_ekt_key_transport" and a new TLS content type called EKTMessage. Using the syntax described in DTLS RFC6347, the following structures are used: If a DTLS client includes srtp_ekt_key_transport in its ClientHello, then a DTLS server that supports this extensions will includes srtp_ekt_key_transport in its ServerHello message.  If a DTLS client includes srtp_ekt_key_transport in its ClientHello, but does not receive srtp_ekt_key_transport in the ServerHello, the DTLS client MUST NOT send DTLS EKTMessage messages.  Also, the srtp_ekt_key_transport in the ServerHello MUST select one and only one EKTCipherType from the list provided by the client in the srtp_ekt_key_transport in the ClientHello. When a DTLS client sends the srtp_ekt_key_transport in its ClientHello message, it MUST include the SupportedEKTCiphers as the extension_data for the extension, listing the EKTCipherTypes the client is willing to use in preference order, with the most preferred version first.  When the server responds in the srtp_ekt_key_transport in its ServerHello message, it MUST include a SupportedEKTCiphers list that selects a single EKTCipherType to use (selected from the list provided by the client) or it returns an empty list to indicate there is no matching EKTCipherType in the clients list that the server is also willing to use.  The value to be used in the EKTCipherType for future extensions that define new ciphers is the value from the "EKT Ciphers Type" IANA registry defined in iana-ciphers. The figure above defines the contents for a new TLS content type called EKTMessage which is registered in iana-tls-content.  The EKTMessage above is used as the opaque fragment in the TLSPlaintext structure defined in Section 6.2.1 of RFC5246 and the srtp_ekt_message as the content type.  The srtp_ekt_message content type is defined and registered in iana-tls-ext. When the Server wishes to provide a new EKT Key, it can send EKTMessage containing an EKTKey with the new key information.  The client MUST respond with an EKTMessage of type ekt_key_act, if the EKTKey was successfully processed and stored or respond with the the ekt_key_error EKTMessage otherwise. The diagram below shows a message flow of DTLS client and DTLS server using the DTLS-SRTP Key Transport extension. Note that when used in PERC I-D.ietf-perc-private-media-framework, the Server is actually split between the Media Distrbutor and Key Distributor.  The messages in the above figure that are "SRTP packets" will not got to the Key Distributor but the other packets will be relayed by the Media Distributor to the Key Distributor. </del> <ins> This document defines a new TLS negotiated extension and a new TLS handshake message type .  The extension negotiates the cipher to be used in encrypting and decrypting EKTCiphertext values, and the handshake message carries the corresponding key. The diagram below shows a message flow of DTLS 1.3 client and server using EKT configured using the DTLS extensions described in this section.  (The initial cookie exchange and other normal DTLS messages are omitted.) In the context of a multi-party SRTP session in which each endpoint performs a DTLS handshake as a client with a central DTLS server, the extensions defined in this session allow the DTLS server to set a common EKT key among all participants.  Each endpoint can then use EKT tags encrypted with that common key to inform other endpoint of the keys it is using to protect SRTP packet.  This avoids the need for many individual DTLS handshakes among the endpoints, at the cost of preventing endpoints from directly authenticating one another. 5.2.1. To indicate its support for EKT, a DTLS-SRTP client includes in its ClientHello an extension of type listing the EKT ciphers the client supports in preference order, with the most preferred version first.  If the server agrees to use EKT, then it includes a extension in its ServerHello containing a cipher selected from among those advertised by the client. The field of this extension contains an "EKTCipher" value, encoded using the syntax defined in RFC5246: 5.2.2. Once a client and server have concluded a handshake that negotiated an EKT cipher, the server MUST provide to the client a key to be used when encrypting and decrypting EKTCiphertext values.  EKT keys are sent in encrypted handshake records, using handshake type .  The body of the handshake message contains an structure: [[ NOTE: RFC Editor, please replace "TBD" above with the code point assigend by IANA ]] The contents of the fields in this message are as follows: If the server did not provide a extension in its ServerHello, then EKTKey messages MUST NOT be sent by either the client or the server. When an EKTKey is received and processed successfully, the recipient MUST respond with an Ack handshake message as described in Section 7 of I-D.ietf-tls-dtls13.  The EKTKey message and Ack must be retransmitted following the rules in Secton 4.2.4 of RFC6347. Note: To be clear, EKT can be used with versions of DTLS prior to 1.3.  The only difference is that in a pre-1.3 TLS stacks will not have built-in support for generating and processing Ack messages. If an EKTKey message is received that cannot be processed, then the recipient MUST respond with an appropriate DTLS alert. </ins> 5.3.


5.4. <del> The DTLS ekt_key is sent using the retransmissions specified in Section 4.2.4.  of DTLS RFC6347. </del> <ins> The DTLS message is sent using the retransmissions specified in Section 4.2.4. of DTLS RFC6347.  Retransmission is finished with an Ack message or an alert is received. </ins> 6.


7.3. <del> IANA is requested to add srtp_ekt_key_transport as a new extension name to the "ExtensionType Values" table of the "Transport Layer Security (TLS) Extensions" registry with a reference to this specification and allocate a value of TBD to for this.  Note to RFC Editor: TBD will be allocated by IANA. </del> <ins> IANA is requested to add as a new extension name to the "ExtensionType Values" table of the "Transport Layer Security (TLS) Extensions" registry with a reference to this specification and allocate a value of TBD to for this. [[ Note to RFC Editor: TBD will be allocated by IANA. ]] </ins> Considerations for this type of extension are described in Section 5 of RFC4366 and requires "IETF Consensus". 7.4. <del> IANA is requested to add srtp_ekt_message as an new descriptions name to the "TLS ContentType Registry" table of the "Transport Layer Security (TLS) Extensions" registry with a reference to this specification, a DTLS-OK value of "Y", and allocate a value of TBD to for this content type.  Note to RFC Editor: TBD will be allocated by IANA. </del> <ins> IANA is requested to add as a new entry in the "TLS HandshakeType Registry" table of the "Transport Layer Security (TLS) Parameters" registry with a reference to this specification, a DTLS-OK value of "Y", and allocate a value of TBD to for this content type. [[ Note to RFC Editor: TBD will be allocated by IANA. ]] </ins> This registry was defined in Section 12 of RFC5246 and requires "Standards Action".


a ciphertext value C with a length of N bytes. <del> The decryption function returns a plaintext value P that is at least M bytes long, or returns an indication that the decryption operation failed because the ciphertext was invalid (i.e. it was not generated by the encryption of plaintext with the key K). These functions have the property that D(K, E(K, P)) = ( P concatenated with optional padding) for all values of K and P.  Each cipher also has a limit T on the number of times that it can be used with any fixed key value.  The EKTKey MUST NOT be used for encryption more that T times.  Note that if the same EKT packet is retransmitted 3 times, that only counts as 1 encryption. </del> <ins> The decryption function returns a plaintext value P that is M bytes long, or returns an indication that the decryption operation failed because the ciphertext was invalid (i.e. it was not generated by the encryption of plaintext with the key K). These functions have the property that D(K, E(K, P)) = P for all values of K and P.  Each cipher also has a limit T on the number of times that it can be used with any fixed key value.  The EKTKey MUST NOT be used for encryption more that T times.  Note that if the same EKT packet is retransmitted 3 times, that only counts as 1 encryption. </ins> Security requirements for EKT ciphers are discussed in sec.


other aspects of EKT processing.  EKT ciphers are free to use this field in any way, but they SHOULD NOT use other EKT or SRTP fields as an input.  The values of the parameters L, and T MUST be defined by <del> each EKTCipher. </del> <ins> each EKTCipher.  The cipher MUST provide integrity protection. </ins> 2.5.


2.2. <del> For several types of events, it is sometimes impossible to tie them to a specific conceptual QUIC connection (e.g., a packet_dropped event triggered because the packet has an unknown connection_id in the header).  Since qlog events in a trace are typically associated with a single connection, it is unclear how to log these events. Ideally, implementers SHOULD create a separate, individual "endpoint- level" trace file (or group_id value), not associated with a specific connection (for example a "server.qlog" or group_id = "client"), and log all events that do not belong to a single connection to this grouping trace.  However, this is not always practical, depending on the implementation.  Because the semantics of most of these events are well-defined in the protocols and because they are difficult to mis-interpret as belonging to a connection, implementers MAY choose to log events not belonging to a particular connection in any other trace, even those strongly associated with a single connection. Note that this can make it difficult to match logs from different vantage points with each other.  For example, from the client side, it is easy to log connections with version negotiation or retry in the same trace, while on the server they would most likely be logged in separate traces.  Servers can take extra efforts (and keep additional state) to keep these events combined in a single trace however (for example by also matching connections on their four-tuple instead of just the connection ID). </del> <ins> A single qlog event trace is typically associated with a single QUIC connection.  However, for several types of events (for example, a transport-packetdropped event with trigger value of "connection_unknown"), it can be impossible to tie them to a specific QUIC connection, especially on the server. There are various ways to handle these events, each making certain tradeoffs between file size overhead, flexibility, ease of use, or ease of implementation.  Some options include: Log them in a separate endpoint-wide trace (or use a special group_id value) not associated with a single connection. Log them in the most recently used trace. Use additional heuristics for connection identification (for example use the four-tuple in addition to the Connection ID). Buffer events until they can be assigned to a connection (for example for version negotiation and retry events). </ins> 3.


QUIC version 2 endpoints MUST implement the QUIC version 1 specification as described in QUIC, QUIC-TLS, and RFC9002, with the <del> following changes: </del> <ins> following changes. </ins> <del> The version field of long headers is 0x709a50c4. </del> <ins> 3.1. </ins> <del> The salt used to derive Initial keys in Section 5.2 of QUIC-TLS changes to: </del> <ins> The version field of long headers is 0x709a50c4. </ins> <del> The labels used in QUIC-TLS to derive packet protection keys (Section Section 5.1 of QUIC-TLS), header protection keys (Section Section 5.4 of QUIC-TLS), Retry Integrity Tag keys (Section Section 5.8 of QUIC-TLS), and key updates (Section Section 6.1 of QUIC-TLS) change from "quic key" to "quicv2 key", from "quic iv" to "quicv2 iv", from "quic hp" to "quicv2 hp", and from "quic ku" to "quicv2 ku", to meet the guidance for new versions in Section Section 9.6 of QUIC-TLS of that document. </del> <ins> 3.2. </ins> <del> The key and nonce used for the Retry Integrity Tag (Section 5.8 of QUIC-TLS) change to: </del> <ins> Initial packets use a packet type field of 0b01. 0-RTT packets use a packet type field of 0b10.  Handshake packets use a packet type field of 0b11.  Retry packets use a packet type field of 0b00. 3.3. 3.3.1. The salt used to derive Initial keys in Section 5.2 of QUIC-TLS changes to: 3.3.2. The labels used in QUIC-TLS to derive packet protection keys (Section Section 5.1 of QUIC-TLS), header protection keys (Section Section 5.4 of QUIC-TLS), Retry Integrity Tag keys (Section Section 5.8 of QUIC-TLS), and key updates (Section Section 6.1 of QUIC-TLS) change from "quic key" to "quicv2 key", from "quic iv" to "quicv2 iv", from "quic hp" to "quicv2 hp", and from "quic ku" to "quicv2 ku", to meet the guidance for new versions in Section Section 9.6 of QUIC-TLS of that document. 3.3.3. The key and nonce used for the Retry Integrity Tag (Section 5.8 of QUIC-TLS) change to: </ins> 4.


Finally QUIC-VN provides two mechanisms for endpoints to negotiate the QUIC version to use.  The "incompatible" version negotiation <del> method can support switching from any initial QUIC version to any other version with full generality, at the cost of an additional round-trip at the start of the connection.  "Compatible" version negotiation eliminates the round-trip penalty but levies some restrictions on how much the two versions can differ semantically. </del> <ins> method can support switching from any QUIC version to any other version with full generality, at the cost of an additional round-trip at the start of the connection.  "Compatible" version negotiation eliminates the round-trip penalty but levies some restrictions on how much the two versions can differ semantically. </ins> QUIC version 2 is meant to mitigate ossification concerns and exercise the version negotiation mechanisms.  The only change is a


data, unless priorities specified by the application indicate otherwise (see stream-prioritization). <ins> Even though a sender is encouraged to assemble frames containing up- to-date information every time it sends a packet, it is not forbidden to retransmit frames of lost packets as they are.  A receiver MUST accept packets containing an outdated frame, such as a MAX_DATA frame carrying a smaller maximum data than one found in an older packet. </ins> Upon detecting losses, a sender MUST take appropriate congestion control action.  The details of loss detection and congestion control are described in QUIC-RECOVERY.


QUIC Stream ID for a client-initiated bidirectional stream encoded as a variable-length integer.  A client MUST treat receipt of a GOAWAY frame containing a Stream ID of any other type as a connection error <del> of type HTTP_MALFORMED_FRAME. </del> <ins> of type HTTP_WRONG_STREAM. </ins> Clients do not need to send GOAWAY to initiate a graceful shutdown; they simply stop making new requests.  A server MUST treat receipt of


definitions) is closed.  A connection enters the draining state when the idle timeout expires. <del> Each endpoint advertises its own idle timeout to its peer.  The idle timeout starts from the last packet received.  In order to ensure that initiating new activity postpones an idle timeout, an endpoint restarts this timer when sending a packet.  An endpoint does not postpone the idle timeout if another packet has been sent containing frames other than ACK or PADDING, and that other packet has not been acknowledged or declared lost.  Packets that contain only ACK or PADDING frames are not acknowledged until an endpoint has other frames to send, so they could prevent the timeout from being refreshed. </del> <ins> Each endpoint advertises its own idle timeout to its peer.  An enpdpoint restarts any timer it maintains when a packet from its peer is received and processed successfully.  The timer is also restarted when sending a packet containing frames other than ACK or PADDING (an ACK-eliciting packet, see QUIC-RECOVERY), but only if no other ACK- eliciting packets have been sent since last receiving a packet. Restarting when sending packets ensures that connections do not prematurely time out when initiating new activity. </ins> The value for an idle timeout can be asymmetric.  The value advertised by an endpoint is only used to determine whether the


result is smaller than the min_rtt, the RTT should be used, but the ack delay field should be ignored. <del> A sender calculates both smoothed RTT and RTT variance similar to those specified in RFC6298, see on-ack-received. </del> <ins> A sender calculates both smoothed RTT (SRTT) and RTT variance (RTTVAR) similar to those specified in RFC6298, see on-ack-received. </ins> A sender takes an RTT sample when an ACK frame is received that acknowledges a larger packet number than before (see on-ack-


available and unused connection IDs.  While each endpoint independently chooses how many connection IDs to issue, endpoints SHOULD provide and maintain at least eight connection IDs.  The <del> endpoint SHOULD do this by always supplying a new connection ID when a connection ID is retired by its peer or when the endpoint receives a packet with a previously unused connection ID.  Endpoints that initiate migration and require non-zero-length connection IDs SHOULD provide their peers with new connection IDs before migration, or risk the peer closing the connection. </del> <ins> endpoint SHOULD do this by supplying a new connection ID when a connection ID is retired by its peer or when the endpoint receives a packet with a previously unused connection ID.  However, it MAY limit the frequency or the total number of connection IDs issued for each connection to avoid the risk of running out of connection IDs (see reset-token). An endpoint that initiates migration and requires non-zero-length connection IDs SHOULD ensure that the pool of connection IDs available to its peer allows the peer to use a new connection ID on migration, as the peer will close the connection if the pool is exhausted. </ins> 5.1.2.


Data is protected using a number of encryption levels: <del> Plaintext </del> <ins> Initial Keys </ins> Early Data (0-RTT) Keys


using the KDF provided by TLS.  In TLS 1.3, the HKDF-Expand-Label function described in Section 7.1 of TLS13 is used, using the hash function from the negotiated cipher suite.  Other versions of TLS <del> MUST provide a similar function in order to be used QUIC. </del> <ins> MUST provide a similar function in order to be used with QUIC. </ins> The current encryption level secret and the label "quic key" are input to the KDF to produce the AEAD key; the label "quic iv" is used


in hexadecimal notation.  Future versions of QUIC SHOULD generate a new salt value, thus ensuring that the keys are different for each version of QUIC.  This prevents a middlebox that only recognizes one <del> version of QUIC from seeing or modifying the contents of handshake packets from future versions. </del> <ins> version of QUIC from seeing or modifying the contents of packets from future versions. </ins> The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for Initial packets even where the TLS versions offered do not include


The "extension_data" field of the quic_transport_parameters extension contains a value that is defined by the version of QUIC that is in use.  The quic_transport_parameters extension carries a <del> TransportParameters when the version of QUIC defined in QUIC- </del> <ins> TransportParameters struct when the version of QUIC defined in QUIC- </ins> TRANSPORT is used. The quic_transport_parameters extension is carried in the ClientHello


Servers SHOULD NOT increase the QUIC MAX_STREAM_ID limit after sending a GOAWAY frame. <del> Once GOAWAY is sent, the server MUST reject requests sent on streams with an identifier greater than or equal to the indicated last Stream ID.  Clients MUST NOT send new requests on the connection after receiving GOAWAY, although requests might already be in transit.  A new connection can be established for new requests. If the client has sent requests on streams with a Stream ID greater than or equal to that indicated in the GOAWAY frame, those requests are considered rejected (request-cancellation).  Clients SHOULD cancel any requests on streams above this ID.  Servers MAY also reject requests on streams below the indicated ID if these requests were not processed. </del> <ins> Clients MUST NOT send new requests on the connection after receiving GOAWAY; a new connection MAY be established to send additional requests. Some requests might already be in transit.  If the client has already sent requests on streams with a Stream ID greater than or equal to that indicated in the GOAWAY frame, those requests will not be processed and MAY be retried by the client on a different connection. The client MAY cancel these requests.  It is RECOMMENDED that the server explicitly reject such requests (see request-cancellation) in order to clean up transport state for the affected streams. </ins> Requests on Stream IDs less than the Stream ID in the GOAWAY frame <del> might have been processed; their status cannot be known until they are completed successfully, reset individually, or the connection terminates. </del> <ins> might have been processed; their status cannot be known until a response is received, the stream is reset individually, or the connection terminates.  Servers MAY reject individual requests on streams below the indicated ID if these requests were not processed. </ins> Servers SHOULD send a GOAWAY frame when the closing of a connection is known in advance, even if the advance notice is small, so that the


A client MUST NOT send a DUPLICATE_PUSH frame.  A server MUST treat the receipt of a DUPLICATE_PUSH frame as a connection error of type <del> HTTP_MALFORMED_FRAME. </del> <ins> HTTP_UNEXPECTED_FRAME. </ins> The DUPLICATE_PUSH frame carries a single variable-length integer that identifies the Push ID of a resource that the server has


can be mounted using spoofed source addresses.  In determining this limit, servers only count the size of successfully processed packets. <del> Clients MUST ensure that UDP datagrams containing Initial packets are sized to at least 1200 bytes, adding padding to packets in the datagram as necessary.  Once a client has received an acknowledgment for a Handshake packet it MAY send smaller datagrams.  Sending padded datagrams ensures that the server is not overly constrained by the amplification restriction. </del> <ins> Clients MUST ensure that UDP datagrams containing only Initial packets are sized to at least 1200 bytes, adding padding to packets in the datagram as necessary.  Sending padded datagrams ensures that the server is not overly constrained by the amplification restriction. </ins> Packet loss, in particular loss of a Handshake packet from the server, can cause a situation in which the server cannot send when


though 1-RTT keys are available to a server after receiving the first handshake messages from a client, the server cannot consider the client to be authenticated until it receives and validates the <del> client's Finished message. </del> <ins> client's Finished message.  A server MUST NOT process 1-RTT packets until the handshake is complete.  A server MAY buffer or discard 1-RTT packets that it cannot read. </ins> The requirement for the server to wait for the client Finished message creates a dependency on that message being delivered.  A


contain frames. QUIC payloads MUST contain at least one frame, and MAY contain <del> multiple frames and multiple frame types. </del> <ins> multiple frames and multiple frame types.  Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC packet boundary. </ins> <del> Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC packet boundary.  Each frame begins with a Frame Type, indicating its type, followed by additional type-dependent fields: </del> <ins> Each frame begins with a Frame Type, indicating its type, followed by additional type-dependent fields: </ins> The frame types defined in this specification are listed in frame- types.  The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED,


the frame.  These frames are explained in more detail in frame- formats. <ins> An endpoint MUST treat the receipt of a frame of unknown type as a connection error of type FRAME_ENCODING_ERROR. </ins> All QUIC frames are idempotent in this version of QUIC.  That is, a valid frame does not cause undesirable side effects or errors when received more than once.


connections.  Servers MAY discard any Initial packet that does not carry the expected token. <ins> A token SHOULD be constructed for the server to easily distinguish it from tokens that are sent in Retry packets as they are carried in the same field. The token MUST NOT include information that would allow it to be linked by an on-path observer to the connection on which it was issued.  For example, it cannot include the connection ID or addressing information unless the values are encrypted. </ins> Unlike the token that is created for a Retry packet, there might be some time between when the token is created and when the token is <del> subsequently used.  Thus, a token SHOULD include an expiration time. The server MAY include either an explicit expiration time or an issued timestamp and dynamically calculate the expiration time.  It is also unlikely that the client port number is the same on two </del> <ins> subsequently used.  Thus, a token SHOULD have an expiration time, which could be either an explicit expiration time or an issued timestamp that can be used to dynamically calculate the expiration time.  A server can store the expiration time or include it in an encrypted form in the token. It is unlikely that the client port number is the same on two </ins> different connections; validating the port is therefore unlikely to be successful. <del> A token SHOULD be constructed for the server to easily distinguish it from tokens that are sent in Retry packets as they are carried in the same field. </del> If the client has a token received in a NEW_TOKEN frame on a previous connection to what it believes to be the same server, it SHOULD include that value in the Token field of its Initial packet.


Before a TLS ciphersuite can be used with QUIC, a header protection algorithm MUST be specified for the AEAD used with that ciphersuite. This document defines algorithms for AEAD_AES_128_GCM, <del> AEAD_AES_128_CCM, AEAD_AES_256_GCM, AEAD_AES_256_CCM (all AES AEADs are defined in AEAD), and AEAD_CHACHA20_POLY1305 CHACHA.  Prior to TLS selecting a ciphersuite, AES header protection is used (hp-aes), matching the AEAD_AES_128_GCM packet protection. </del> <ins> AEAD_AES_128_CCM, AEAD_AES_256_GCM (all AES AEADs are defined in AEAD), and AEAD_CHACHA20_POLY1305 CHACHA.  Prior to TLS selecting a ciphersuite, AES header protection is used (hp-aes), matching the AEAD_AES_128_GCM packet protection. </ins> 5.4.2.


5.4.3. This section defines the packet protection algorithm for <del> AEAD_AES_128_GCM, AEAD_AES_128_CCM, AEAD_AES_256_GCM, and AEAD_AES_256_CCM.  AEAD_AES_128_GCM and AEAD_AES_128_CCM use 128-bit AES AES in electronic code-book (ECB) mode.  AEAD_AES_256_GCM, and AEAD_AES_256_CCM use 256-bit AES in ECB mode. </del> <ins> AEAD_AES_128_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_GCM. AEAD_AES_128_GCM and AEAD_AES_128_CCM use 128-bit AES AES in electronic code-book (ECB) mode.  AEAD_AES_256_GCM uses 256-bit AES in ECB mode. </ins> This algorithm samples 16 bytes from the packet ciphertext.  This value is used as the input to AES-ECB.  In pseudocode:


8.1. <del> The QUIC version negotiation mechanism is used to negotiate the version of QUIC that is used prior to the completion of the handshake.  However, this packet is not authenticated, enabling an active attacker to force a version downgrade. To ensure that a QUIC version downgrade is not forced by an attacker, version information is copied into the TLS handshake, which provides integrity protection for the QUIC negotiation.  This does not prevent version downgrade prior to the completion of the handshake, though it means that a downgrade causes a handshake failure. </del> QUIC requires that the cryptographic handshake provide authenticated protocol negotiation.  TLS uses Application Layer Protocol Negotiation (ALPN) RFC7301 to select an application protocol.  Unless


have been lost or discarded by the server.  A client MAY attempt to resend data in 0-RTT packets after it sends a new Initial packet. <del> A client MUST NOT reset the packet number it uses for 0-RTT packets. The keys used to protect 0-RTT packets will not change as a result of responding to a Retry packet unless the client also regenerates the cryptographic handshake message.  Sending packets with the same packet number in that case is likely to compromise the packet </del> <ins> A client MUST NOT reset the packet number it uses for 0-RTT packets, since the keys used to protect 0-RTT packets will not change as a result of responding to a Retry packet.  Sending packets with the same packet number in that case is likely to compromise the packet </ins> protection for all 0-RTT packets because the same key and nonce could be used to protect different content.


from a packet number of 0.  Thus, 0-RTT packets could need to use a longer packet number encoding. <del> A client SHOULD instead generate a fresh cryptographic handshake message and start packet numbers from 0.  This ensures that new 0-RTT packets will not use the same keys, avoiding any risk of key and nonce reuse; this also prevents 0-RTT packets from previous handshake attempts from being accepted as part of the connection. </del> A client MUST NOT send 0-RTT packets once it starts processing 1-RTT packets from the server.  This means that 0-RTT packets cannot contain any response to frames from 1-RTT packets.  For instance, a


compression-induced head-of-line blocking.  See that document for additional details. <ins> To allow for better compression efficiency, the cookie header field RFC6265 MAY be split into separate header fields, each with one or more cookie-pairs, before compression.  If a decompressed header list contains multiple cookie header fields, these MUST be concatenated before being passed into a non-HTTP/2, non-HTTP/3 context, as described in HTTP2, Section 8.1.2.5. </ins> An HTTP/3 implementation MAY impose a limit on the maximum size of the message header it will accept on an individual HTTP message.  A server that receives a larger header field list than it is willing to


The most appropriate error code (error-codes) SHOULD be included in the frame that signals the error.  Where this specification identifies error conditions, it also identifies the error code that <del> is used. </del> <ins> is used; though these are worded as requirements, different implementation strategies might lead to different errors being reported.  In particular, an endpoint MAY use any applicable error code when it detects an error condition; a generic error code (such as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place of specific error codes. </ins> A stateless reset (stateless-reset) is not suitable for any error that can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame.


See iana-error-codes for details of registering new error codes. <ins> In defining these error codes, several principles are applied.  Error conditions that might require specific action on the part of a recipient are given unique codes.  Errors that represent common conditions are given specific codes.  Absent either of these conditions, error codes are used to identify a general function of the stack, like flow control or transport parameter handling. Finally, generic errors are provided for conditions where implementations are unable or unwilling to use more specific codes. </ins> 20.1. Application protocol error codes are 62-bit unsigned integers, but


process performed at the beginning of the connection SHOULD be applied for all paths used by the connection. <del> In case multiple connections share the same network path, as determined by having the same source and destination IP address and UDP ports, endpoints should try to co-ordinate across all connections to ensure a clear signal to any on-path measurement points. </del> When the spin bit is disabled, endpoints MAY set the spin bit to any value, and MUST ignore any incoming value.  It is RECOMMENDED that endpoints set the spin bit to a random value either chosen


Indicates that x is A bits long Indicates that x uses the prefixed integer encoding defined in <del> Section 5.1 of RFC7541, beginning with an A-bit prefix. </del> <ins> prefixed-integers, beginning with an A-bit prefix. </ins> Indicates that x is variable-length and extends to the end of the region.


An encoder informs the decoder of a change to the dynamic table capacity using an instruction which begins with the '001' three-bit <del> pattern.  The new dynamic table capacity is represented as an integer with a 5-bit prefix (see Section 5.1 of RFC7541). </del> <ins> pattern.  This is followed by the new dynamic table capacity represented as an integer with a 5-bit prefix (see prefixed- integers). </ins> The new capacity MUST be lower than or equal to the limit described in maximum-dynamic-table-capacity.  In HTTP/3, this limit is the


or the dynamic table using an instruction that starts with the '1' one-bit pattern.  The second ("S") bit indicates whether the reference is to the static or dynamic table.  The 6-bit prefix <del> integer (see Section 5.1 of RFC7541) that follows is used to locate the table entry for the header name.  When S=1, the number represents the static table index; when S=0, the number is the relative index of the entry in the dynamic table. </del> <ins> integer (see prefixed-integers) that follows is used to locate the table entry for the header name.  When S=1, the number represents the static table index; when S=0, the number is the relative index of the entry in the dynamic table. </ins> The header name reference is followed by the header field value <del> represented as a string literal (see Section 5.2 of RFC7541). </del> <ins> represented as a string literal (see string-literals). </ins> 4.3.3. An encoder adds an entry to the dynamic table where both the header field name and the header field value are represented as string <del> literals (see primitives) using an instruction that starts with the '01' two-bit pattern. </del> <ins> literals using an instruction that starts with the '01' two-bit pattern. </ins> <del> The name is represented as a 6-bit prefix string literal, while the value is represented as an 8-bit prefix string literal. </del> <ins> This is followed by the name represented as a 6-bit prefix string literal, and the value represented as an 8-bit prefix string literal (see string-literals). </ins> 4.3.4. An encoder duplicates an existing entry in the dynamic table using an <del> instruction that starts with the '000' three-bit pattern.  The relative index of the existing entry is represented as an integer with a 5-bit prefix. </del> <ins> instruction that begins with the '000' three-bit pattern.  This is followed by the relative index of the existing entry represented as an integer with a 5-bit prefix (see prefixed-integers. </ins> The existing entry is re-inserted into the dynamic table without resending either the name or the value.  This is useful to mitigate


After processing a header block whose declared Required Insert Count is not zero, the decoder emits a Header Acknowledgement instruction. <del> The instruction begins with the '1' one-bit pattern and includes the header block's associated stream ID, encoded as a 7-bit prefix integer.  It is used by the peer's encoder to know when it is safe to evict an entry (blocked-insertion), and possibly update the Known Received Count (known-received-count). </del> <ins> The instruction begins with the '1' one-bit pattern which is followed by the header block's associated stream ID encoded as a 7-bit prefix integer (see prefixed-integers). This instruction is used as described in known-received-count and in state-synchronization. </ins> If an encoder receives a Header Acknowledgement instruction referring to a stream on which every header block with a non-zero Required


When a stream is reset or reading is abandoned, the decoder emits a Stream Cancellation instruction.  The instruction begins with the <del> '01' two-bit pattern.  The instruction includes the stream ID of the affected stream encoded as a 6-bit prefix integer.  See state- synchronization. </del> <ins> '01' two-bit pattern, which is followed by the stream ID of the affected stream encoded as a 6-bit prefix integer. This instruction is used as described in state-synchronization. </ins> 4.4.3. The Insert Count Increment instruction begins with the '00' two-bit <del> pattern.  The instruction specifies the total number of dynamic table inserts and duplications since the last Insert Count Increment or Header Acknowledgement that increased the Known Received Count for the dynamic table (see known-received-count).  The Increment field is encoded as a 6-bit prefix integer.  The encoder uses this value to determine which table entries might cause a stream to become blocked, as described in state-synchronization. </del> <ins> pattern, followed by the Increment encoded as a 6-bit prefix integer. The value of the Increment is the total number of dynamic table insertions and duplications processed by the decoder since the last time it sent a Header Acknowledgement instruction that increased the Known Received Count (see known-received-count) or an Insert Count Increment instruction.  The encoder uses this value to update the Known Received Count, as described in state-synchronization. </ins> An encoder that receives an Increment field equal to zero or one that increases the Known Received Count beyond what the encoder has sent


4.5. <del> Header blocks contain compressed representations of header lists and are carried in frames on streams defined by the enclosing protocol. These representations reference the static table, or dynamic table in a particular state without modifying it. </del> <ins> A header block consists of a prefix and a possibly empty sequence of representations defined in this section.  Each representation corresponds to a single header field.  These representations reference the static table or the dynamic table in a particular state, but do not modify that state. Header blocks are carried in frames on streams defined by the enclosing protocol. </ins> 4.5.1.


absolute index less than the Base, this representation starts with the '1' 1-bit pattern, followed by the "S" bit indicating whether the reference is into the static or dynamic table.  The 6-bit prefix <del> integer (see Section 5.1 of RFC7541) that follows is used to locate the table entry for the header name.  When S=1, the number represents </del> <ins> integer (see prefixed-integers) that follows is used to locate the table entry for the header field.  When S=1, the number represents </ins> the static table index; when S=0, the number is the relative index of the entry in the dynamic table.


than or equal to the Base, the representation starts with the '0001' 4-bit pattern, followed by the post-base index (see post-base) of the matching header field, represented as an integer with a 4-bit prefix <del> (see Section 5.1 of RFC7541). </del> <ins> (see prefixed-integers). </ins> 4.5.4.


absolute index less than the Base, this representation starts with the '01' two-bit pattern. <del> Only the header field name stored in the static or dynamic table is used.  Any header field value MUST be ignored. </del> The following bit, 'N', indicates whether an intermediary is permitted to add this header to the dynamic header table on subsequent hops.  When the 'N' bit is set, the encoded header MUST


header field with the 'N' bit set, it MUST use a literal representation to forward this header field.  This bit is intended for protecting header field values that are not to be put at risk by <del> compressing them (see Section 7.1 of RFC7541 for more details). </del> <ins> compressing them (see security-considerations for more details). </ins> The fourth ("S") bit indicates whether the reference is to the static <del> or dynamic table.  The 4-bit prefix integer (see Section 5.1 of RFC7541) that follows is used to locate the table entry for the header name.  When S=1, the number represents the static table index; when S=0, the number is the relative index of the entry in the dynamic table. </del> <ins> or dynamic table.  The 4-bit prefix integer (see prefixed-integers) that follows is used to locate the table entry for the header name. When S=1, the number represents the static table index; when S=0, the number is the relative index of the entry in the dynamic table. Only the header field name is taken from the dynamic table entry; the header field value is encoded as an 8-bit prefix string literal (see string-literals). </ins> 4.5.5. <del> If the name entry is in the dynamic table with an absolute index greater than or equal to the Base, the representation starts with the '0000' four-bit pattern.  The fifth bit is the 'N' bit as described in literal-name-reference.  Finally, the header field name is represented using the post-base index of that entry (see post-base) encoded as an integer with a 3-bit prefix. </del> <ins> A literal header field with post-base name reference represents a header field where the name matches the header field name of a dynamic table entry with an absolute index greater than or equal to the Base. This representation starts with the '0000' four-bit pattern.  The fifth bit is the 'N' bit as described in literal-name-reference. This is followed by a post-base index of the dynamic table entry (see post-base) encoded as an integer with a 3-bit prefix (see prefixed- integers). Only the header field name is taken from the dynamic table entry; the header field value is encoded as an 8-bit prefix string literal (see string-literals). </ins> 4.5.6. <del> An addition to the header table where both the header field name and the header field value are represented as string literals (see primitives) starts with the '001' three-bit pattern. The fourth bit, 'N', indicates whether an intermediary is permitted to add this header to the dynamic header table on subsequent hops. When the 'N' bit is set, the encoded header MUST always be encoded with a literal representation.  In particular, when a peer sends a header field that it received represented as a literal header field with the 'N' bit set, it MUST use a literal representation to forward this header field.  This bit is intended for protecting header field values that are not to be put at risk by compressing them (see Section 7.1 of RFC7541 for more details). The name is represented as a 4-bit prefix string literal, while the value is represented as an 8-bit prefix string literal. </del> <ins> The literal header field without name reference representation encodes a header field name and header field value as string literals. This representation begins with the '001' three-bit pattern.  The fourth bit is the 'N' bit as described in literal-name-reference. The name follows, represented as a 4-bit prefix string literal, then the value, represented as an 8-bit prefix string literal (see string- literals). </ins> 5.


RETIRE_CONNECTION_ID frames and retransmitted if the packet containing them is lost. <ins> NEW_TOKEN frames are retransmitted if the packet containing them is lost.  No special support is made for detecting reordered and duplicated NEW_TOKEN frames other than a direct comparison of the frame contents. </ins> PING and PADDING frames contain no information, so lost PING or PADDING frames do not require repair.


An opaque blob that the client may use with a future Initial packet. <ins> An endpoint might receive multiple NEW_TOKEN frames that contain the same token value.  Endpoints are responsible for discarding duplicate values, which might be used to link connection attempts; see validate-future. </ins> 19.8. STREAM frames implicitly create a stream and carry stream data.  The


10. The security considerations of HTTP/3 should be comparable to those <del> of HTTP/2 with TLS.  Note that where HTTP/2 employs PADDING frames and Padding fields in other frames to make a connection more resistant to traffic analysis, HTTP/3 can either rely on transport- layer padding or employ the reserved frame and stream types discussed in frame-grease and stream-grease. </del> <ins> of HTTP/2 with TLS; the considerations from Section 10 of HTTP2 apply in addition to those listed here. </ins> When HTTP Alternative Services is used for discovery for HTTP/3 endpoints, the security considerations of ALTSVC also apply. <ins> 10.1. Where HTTP/2 employs PADDING frames and Padding fields in other frames to make a connection more resistant to traffic analysis, HTTP/3 can either rely on transport-layer padding or employ the reserved frame and stream types discussed in frame-grease and stream- grease.  These methods of padding produce different results in terms of the granularity of padding, the effect of packet loss and recovery, and how an implementation might control padding. 10.2. </ins> Several protocol elements contain nested length elements, typically in the form of frames with an explicit length containing variable- length integers.  This could pose a security risk to an incautious implementer.  An implementation MUST ensure that the length of a frame exactly matches the length of the fields it contains. <ins> 10.3. </ins> The use of 0-RTT with HTTP/3 creates an exposure to replay attack. The anti-replay mitigations in HTTP-REPLAY MUST be applied when using HTTP/3 with 0-RTT. <ins> 10.4. </ins> Certain HTTP implementations use the client address for logging or access-control purposes.  Since a QUIC client's address might change during a connection (and future versions might support simultaneous


peer.  For example, a client might be willing to consume a very large response header, while servers are more cautious about request size. <del> Parameters MUST NOT occur more than once in the SETTINGS frame.  A receiver MAY treat the presence of the same parameter more than once as a connection error of type HTTP_SETTINGS_ERROR. </del> <ins> The same setting identifier MUST NOT occur more than once in the SETTINGS frame.  A receiver MAY treat the presence of duplicate setting identifiers as a connection error of type HTTP_SETTINGS_ERROR. </ins> The payload of a SETTINGS frame consists of zero or more parameters. Each parameter consists of a setting identifier and a value, both


ChaCha20 function as defined in Section 2.4 of CHACHA.  This uses a 256-bit key and 16 bytes sampled from the packet protection output. <del> The first 4 bytes of the sampled ciphertext are interpreted as a 32-bit number in little-endian order and are used as the block count. The remaining 12 bytes are interpreted as three concatenated 32-bit numbers in little-endian order and used as the nonce. </del> <ins> The first 4 bytes of the sampled ciphertext are the block counter.  A ChaCha20 implementation could take a 32-bit integer in place of a byte sequence, in which case the byte sequence is interpreted as a little-endian value. The remaining 12 bytes are used as the nonce.  A ChaCha20 implementation might take an array of three 32-bit integers in place of a byte sequence, in which case the nonce bytes are interpreted as a sequence of 32-bit little-endian integers. </ins> The encryption mask is produced by invoking ChaCha20 to protect 5 zero bytes.  In pseudocode:


set to 0. A QUIC packet with a short header includes a Destination Connection <del> ID.  The short header does not include the Connection ID Lengths, Source Connection ID, or Version fields. </del> <ins> ID immediately following the first byte.  The short header does not include the Connection ID Lengths, Source Connection ID, or Version fields.  The length of the Destination Connection ID is not specified in packets with a short header and is not constrained by this specification. </ins> The remainder of the packet has version-specific semantics.


Frame types which were used in HTTP/2 where there is no corresponding HTTP/3 frame have also been reserved (iana-frames).  These frame types MUST NOT be sent, and receipt MAY be treated as an error of <del> type HTTP_UNEXPECTED_FRAME. </del> <ins> type HTTP_FRAME_UNEXPECTED. </ins> 8.


Packets containing only ACK frames are not congestion controlled, so there are limits on how frequently they can be sent.  An endpoint MUST NOT send more than one ACK-frame-only packet in response to <del> receiving an ack-eliciting packet (one containing frames other than ACK and/or PADDING).  An endpoint MUST NOT send a packet containing only an ACK frame in response to a non-ack-eliciting packet (one containing only ACK and/or PADDING frames), even if there are packet gaps which precede the received packet.  Limiting ACK frames avoids an infinite feedback loop of acknowledgements, which could prevent the connection from ever becoming idle.  However, the endpoint acknowledges non-ack-eliciting packets when it sends an ACK frame. </del> <ins> receiving an ack-eliciting packet.  An endpoint MUST NOT send a non- ack-eliciting packet in response to a non-ack-eliciting packet, even if there are packet gaps which precede the received packet.  Limiting ACK frames avoids an infinite feedback loop of acknowledgements, which could prevent the connection from ever becoming idle.  However, the endpoint acknowledges non-ACK-eliciting packets when it sends an ACK frame. </ins> An endpoint SHOULD treat receipt of an acknowledgment for a packet it did not send as a connection error of type PROTOCOL_VIOLATION, if it


frames should therefore not be paced, to avoid delaying their delivery to the peer. <ins> Sending multiple packets into the network without any delay between them creates a packet burst that might cause short-term congestion and losses.  Implementations MUST either use pacing or limit such bursts to minimum of 10 * kMaxDatagramSize and max(2* kMaxDatagramSize, 14720)), the same as the recommended initial congestion window. </ins> As an example of a well-known and publicly available implementation of a flow pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc) in Linux (3.11 onwards).


sender should not consider itself application limited if it would have fully utilized the congestion window without pacing delay. <del> Sending multiple packets into the network without any delay between them creates a packet burst that might cause short-term congestion and losses.  Implementations SHOULD either use pacing or reduce their congestion window to limit such bursts to minimum of 10 * kMaxDatagramSize and max(2* kMaxDatagramSize, 14720)), the same as the recommended initial congestion window. </del> A sender MAY implement alternative mechanisms to update its congestion window after periods of under-utilization, such as those proposed for TCP in RFC7661.


be routed to a server instance with more resources available for new connections. <ins> If a server receives a client Initial that can be unprotected but contains an invalid Retry token, it knows the client will not accept another Retry token.  The server can discard such a packet and allow the client to time out to detect handshake failure, but that could impose a significant latency penalty on the client.  A server MAY proceed with the connection without verifying the token, though the server MUST NOT consider the client address validated.  If a server chooses not to proceed with the handshake, it SHOULD immediately close (immediate-close) the connection with an INVALID_TOKEN error. Note that a server has not established any state for the connection at this point and so does not enter the closing period. </ins> A flow showing the use of a Retry packet is shown in fig-retry. 8.1.2.


An endpoint detected an error with protocol compliance that was not covered by more specific error codes. <ins> A server received a Retry Token in a client Initial that is invalid. </ins> An endpoint has received more data in CRYPTO frames than it can buffer.


4.5.2. <del> An indexed header field representation identifies an entry in either the static table or the dynamic table and causes that header field to be added to the decoded header list. If the entry is in the static table, or in the dynamic table with an absolute index less than the Base, this representation starts with the '1' 1-bit pattern, followed by the 'T' bit indicating whether the reference is into the static or dynamic table.  The 6-bit prefix integer (see prefixed-integers) that follows is used to locate the table entry for the header field.  When T=1, the number represents the static table index; when T=0, the number is the relative index of the entry in the dynamic table. </del> <ins> An indexed header field representation identifies an entry in the static table, or an entry in the dynamic table with an absolute index less than the Base. This representation starts with the '1' 1-bit pattern, followed by the 'T' bit indicating whether the reference is into the static or dynamic table.  The 6-bit prefix integer (see prefixed-integers) that follows is used to locate the table entry for the header field.  When T=1, the number represents the static table index; when T=0, the number is the relative index of the entry in the dynamic table. </ins> 4.5.3. <del> If the entry is in the dynamic table with an absolute index greater than or equal to the Base, the representation starts with the '0001' 4-bit pattern, followed by the post-base index (see post-base) of the matching header field, represented as an integer with a 4-bit prefix (see prefixed-integers). </del> <ins> An indexed header field with post-base index representation identifies an entry in the dynamic table with an absolute index greater than or equal to the Base. </ins> <del> 4.5.4. </del> <ins> This representation starts with the '0001' 4-bit pattern.  This is followed by the post-base index (see post-base) of the matching header field, represented as an integer with a 4-bit prefix (see prefixed-integers). </ins> <del> A literal header field with name reference represents a header field where the header field name matches the header field name of an entry stored in the static table or the dynamic table. If the entry is in the static table, or in the dynamic table with an absolute index less than the Base, this representation starts with the '01' two-bit pattern. </del> <ins> 4.5.4. </ins> <del> The following bit, 'N', indicates whether an intermediary is permitted to add this header to the dynamic header table on subsequent hops.  When the 'N' bit is set, the encoded header MUST always be encoded with a literal representation.  In particular, when a peer sends a header field that it received represented as a literal header field with the 'N' bit set, it MUST use a literal representation to forward this header field.  This bit is intended for protecting header field values that are not to be put at risk by compressing them (see security-considerations for more details). </del> <ins> A literal header field with name reference representation encodes a header field where the header field name matches the header field name of an entry in the static table, or the header field name of an entry in the dynamic table with an absolute index less than the Base. This representation starts with the '01' two-bit pattern.  The following bit, 'N', indicates whether an intermediary is permitted to add this header to the dynamic header table on subsequent hops.  When the 'N' bit is set, the encoded header MUST always be encoded with a literal representation.  In particular, when a peer sends a header field that it received represented as a literal header field with the 'N' bit set, it MUST use a literal representation to forward this header field.  This bit is intended for protecting header field values that are not to be put at risk by compressing them (see security-considerations for more details). </ins> The fourth ('T') bit indicates whether the reference is to the static or dynamic table.  The 4-bit prefix integer (see prefixed-integers)


4.5.5. <del> A literal header field with post-base name reference represents a header field where the name matches the header field name of a dynamic table entry with an absolute index greater than or equal to the Base. </del> <ins> A literal header field with post-base name reference representation encodes a header field where the header field name matches the header field name of a dynamic table entry with an absolute index greater than or equal to the Base. </ins> This representation starts with the '0000' four-bit pattern.  The fifth bit is the 'N' bit as described in literal-name-reference.


4.5.6. The literal header field without name reference representation <del> encodes a header field name and header field value as string </del> <ins> encodes a header field name and a header field value as string </ins> literals. This representation begins with the '001' three-bit pattern.  The


open a connection, which begins the exchange described in handshake; <del> enable 0-RTT; and </del> <ins> enable 0-RTT when available; and </ins> be informed when 0-RTT has been accepted or rejected by a server.


a token that is not applicable to the server that it is connecting to, unless the client has the knowledge that the server that issued the token and the server the client is connecting to are jointly <del> managing the tokens. </del> <ins> managing the tokens.  A client MAY use a token from any previous connection to that server. </ins> A token allows a server to correlate activity between the connection where the token was issued and any connection where it is used.


limit its use of tokens to only the information needed to validate client addresses. <ins> Clients MAY use tokens obtained on one connection for any connection attempt using the same version.  When selecting a token to use, clients do not need to consider other properties of the connection that is being attempted, including the choice of possible application protocols, session tickets, or other connection properties. </ins> Attackers could replay tokens to use servers as amplifiers in DDoS attacks.  To protect against such attacks, servers SHOULD ensure that tokens sent in Retry packets are only accepted for a short time.


write data, understanding when stream flow control credit (data- flow-control) has successfully been reserved to send the written <del> data </del> <ins> data; </ins> end the stream (clean termination), resulting in a STREAM frame (frame-stream) with the FIN bit set; and reset the stream (abrupt termination), resulting in a RESET_STREAM <del> frame (frame-reset-stream), even if the stream was already ended. </del> <ins> frame (frame-reset-stream), if the stream was not already in a terminal state. </ins> On the receiving part of a stream, application protocols need to be able to: <del> read data </del> <ins> read data; and </ins> abort reading of the stream and request closure, possibly <del> resulting in a STOP_SENDING frame (frame-stop-sending) </del> <ins> resulting in a STOP_SENDING frame (frame-stop-sending). </ins> Applications also need to be informed of state changes on streams, including when the peer has opened or reset a stream, when a peer


A Retry packet causes a client to send another Initial packet, effectively restarting the connection process.  A Retry packet indicates that the Initial was received, but not processed.  A Retry <del> packet MUST NOT be treated as an acknowledgment. </del> <ins> packet cannot be treated as an acknowledgment, because it does not indicate that a packet was processed or specify the packet number. </ins> Clients that receive a Retry packet reset congestion control and loss recovery state, including resetting any pending timers.  Other


3.1.3. <del> QUIC ends a loss epoch when a packet sent after loss is declared is acknowledged.  TCP waits for the gap in the sequence number space to be filled, and so if a segment is lost multiple times in a row, the loss epoch may not end for several round trips.  Because both should reduce their congestion windows only once per epoch, QUIC will do it correctly once for every round trip that experiences loss, while TCP may only do it once across multiple round trips. </del> <ins> QUIC starts a loss epoch when a packet is lost and ends one when any packet sent after the epoch starts is acknowledged.  TCP waits for the gap in the sequence number space to be filled, and so if a segment is lost multiple times in a row, the loss epoch may not end for several round trips.  Because both should reduce their congestion windows only once per epoch, QUIC will do it correctly once for every round trip that experiences loss, while TCP may only do it once across multiple round trips. </ins> 3.1.4.


(request-response). Multiplexing of requests is performed using the QUIC stream <del> abstraction, described in Section 2 of QUIC-TRANSPORT.  Each request and response consumes a single QUIC stream.  Streams are independent </del> <ins> abstraction, described in Section 2 of QUIC-TRANSPORT.  Each request- response pair consumes a single QUIC stream.  Streams are independent </ins> of each other, so one stream that is blocked or suffers packet loss does not prevent progress on other streams.


The RECOMMENDED initial value for the packet reordering threshold (kPacketThreshold) is 3, based on best practices for TCP loss <del> detection RFC5681 RFC6675. </del> <ins> detection RFC5681 RFC6675.  Implementations SHOULD NOT use a packet threshold less than 3, to keep in line with TCP RFC5681. </ins> Some networks may exhibit higher degrees of reordering, causing a sender to detect spurious losses.  Implementers MAY use algorithms


Endpoints validate ECN for packets sent on each network path independently.  An endpoint thus validates ECN on new connection establishment, when switching to a new server preferred address, and <del> on active connection migration to a new path. </del> <ins> on active connection migration to a new path.  ecn-alg describes one possible algorithm for testing paths for ECN support. </ins> Even if an endpoint does not use ECN markings on packets it transmits, the endpoint MUST provide feedback about ECN markings


carry this connection ID for the duration of the connection or until its peer invalidates the connection ID via a RETIRE_CONNECTION_ID frame (frame-retire-connection-id).  Connection IDs that are issued <del> and not retired are considered active; any active connection ID can be used. </del> <ins> and not retired are considered active; any active connection ID is valid for use at any time, in any packet type.  This includes the connection ID issued by the server via the preferred_address transport parameter. </ins> An endpoint SHOULD ensure that its peer has a sufficient number of available and unused connection IDs.  Endpoints store received


All HTTP/3 requests MUST include exactly one value for the ":method", ":scheme", and ":path" pseudo-header fields, unless it is a CONNECT <del> request (connect).  An HTTP request that omits mandatory pseudo- header fields or contains invalid values for those fields is malformed (malformed). </del> <ins> request (connect). If the ":scheme" pseudo-header field identifies a scheme which has a mandatory authority component (including "http" and "https"), the request MUST contain either an ":authority" pseudo-header field or a "Host" header field.  If these fields are present, they MUST NOT be empty.  If both fields are present, they MUST contain the same value. If the scheme does not have a mandatory authority component and none is provided in the request target, the request MUST NOT contain the ":authority" pseudo-header and "Host" header fields. An HTTP request that omits mandatory pseudo-header fields or contains invalid values for those fields is malformed (malformed). </ins> HTTP/3 does not define a way to carry the version identifier that is included in the HTTP/1.1 request line.


A packet that does not increase the largest received packet number for its packet number space (packet-numbers) by exactly one.  A <del> packet can arrive out of order if it is delayed or if earlier packets are lost or delayed. </del> <ins> packet can arrive out of order if it is delayed, if earlier packets are lost or delayed, or if the sender intentionally skips a packet number. </ins> An entity that can participate in a QUIC connection by generating, receiving, and processing QUIC packets.  There are only two types


Servers MUST drop incoming packets under all other circumstances. <ins> 5.2.3. A server deployment could load balance among servers using only source and destination IP addresses and ports.  Changes to the client's IP address or port could result in packets being forwarded to the wrong server.  Such a server deployment could use one of the following methods for connection continuity when a client's address changes. Servers could use an out-of-band mechanism to forward packets to the correct server based on Connection ID. If servers can use other dedicated server IP addresses or ports than the one that the client initially connects to, they could use the preferred_address transport parameter to request that clients move connections to these dedicated addresses.  Note that clients could choose not to use the preferred address. A server in a deployment that does not implement a solution to maintain connection continuity during connection migration SHOULD disallow migration using the disable_active_migration transport parameter. Server deployments that use this simple form of load balancing MUST avoid the creation of a stateless reset oracle; see reset-oracle. </ins> 5.3. A QUIC connection is a stateful interaction between a client and


in connection failures, as the issuing endpoint might be unable to continue using the connection IDs with the active connection. <ins> An endpoint SHOULD limit the number of connection IDs it has retired locally and have not yet been acknowledged.  An endpoint SHOULD allow for sending and tracking a number of RETIRE_CONNECTION_ID frames of at least twice the active_connection_id limit.  An endpoint MUST NOT forget a connection ID without retiring it, though it MAY choose to treat having connection IDs in need of retirement that exceed this limit as a connection error of type CONNECTION_ID_LIMIT_ERROR. Endpoints SHOULD NOT issue updates of the Retire Prior To field before receiving RETIRE_CONNECTION_ID frames that retire all connection IDs indicated by the previous Retire Prior To value. </ins> 5.2. Incoming packets are classified on receipt.  Packets can either be


7. <del> TBD.  Also see Section 7.1 of RFC7541. </del> <ins> This section describes potential areas of security concern with QPACK: Use of compression as a length-based oracle for verifying guesses about secrets that are compressed into a shared compression context. Denial of service resulting from exhausting processing or memory capacity at a decoder. 7.1. QPACK reduces the length of header field encodings by exploiting the redundancy inherent in protocols like HTTP.  The ultimate goal of this is to reduce the amount of data that is required to send HTTP requests or responses. The compression context used to encode header fields can be probed by an attacker who can both define header fields to be encoded and transmitted and observe the length of those fields once they are encoded.  When an attacker can do both, they can adaptively modify requests in order to confirm guesses about the dynamic table state. If a guess is compressed into a shorter length, the attacker can observe the encoded length and infer that the guess was correct. This is possible even over the Transport Layer Security Protocol (TLS, see RFC5246), because while TLS provides confidentiality protection for content, it only provides a limited amount of protection for the length of that content. Padding schemes only provide limited protection against an attacker with these capabilities, potentially only forcing an increased number of guesses to learn the length associated with a given guess.  Padding schemes also work directly against compression by increasing the number of bits that are transmitted. Attacks like CRIME CRIME demonstrated the existence of these general attacker capabilities.  The specific attack exploited the fact that DEFLATE RFC1951 removes redundancy based on prefix matching.  This permitted the attacker to confirm guesses a character at a time, reducing an exponential-time attack into a linear-time attack. 7.2. QPACK mitigates but does not completely prevent attacks modeled on CRIME CRIME by forcing a guess to match an entire header field value, rather than individual characters.  An attacker can only learn whether a guess is correct or not, so is reduced to a brute force guess for the header field values. The viability of recovering specific header field values therefore depends on the entropy of values.  As a result, values with high entropy are unlikely to be recovered successfully.  However, values with low entropy remain vulnerable. Attacks of this nature are possible any time that two mutually distrustful entities control requests or responses that are placed onto a single HTTP/3 connection.  If the shared QPACK compressor permits one entity to add entries to the dynamic table, and the other to access those entries, then the state of the table can be learned. Having requests or responses from mutually distrustful entities occurs when an intermediary either: sends requests from multiple clients on a single connection toward an origin server, or takes responses from multiple origin servers and places them on a shared connection toward a client. Web browsers also need to assume that requests made on the same connection by different web origins RFC6454 are made by mutually distrustful entities. 7.3. Users of HTTP that require confidentiality for header fields can use values with entropy sufficient to make guessing infeasible.  However, this is impractical as a general solution because it forces all users of HTTP to take steps to mitigate attacks.  It would impose new constraints on how HTTP is used. Rather than impose constraints on users of HTTP, an implementation of QPACK can instead constrain how compression is applied in order to limit the potential for dynamic table probing. An ideal solution segregates access to the dynamic table based on the entity that is constructing header fields.  Header field values that are added to the table are attributed to an entity, and only the entity that created a particular value can extract that value. To improve compression performance of this option, certain entries might be tagged as being public.  For example, a web browser might make the values of the Accept-Encoding header field available in all requests. An encoder without good knowledge of the provenance of header fields might instead introduce a penalty for a header field with many different values, such that a large number of attempts to guess a header field value results in the header field not being compared to the dynamic table entries in future messages, effectively preventing further guesses. Simply removing entries corresponding to the header field from the dynamic table can be ineffectual if the attacker has a reliable way of causing values to be reinstalled.  For example, a request to load an image in a web browser typically includes the Cookie header field (a potentially highly valued target for this sort of attack), and web sites can easily force an image to be loaded, thereby refreshing the entry in the dynamic table. This response might be made inversely proportional to the length of the header field value.  Disabling access to the dynamic table for a header field might occur for shorter values more quickly or with higher probability than for longer values. 7.4. Implementations can also choose to protect sensitive header fields by not compressing them and instead encoding their value as literals. Refusing to insert a header field into the dynamic table is only effective if doing so is avoided on all hops.  The never indexed literal bit (see literal-name-reference) can be used to signal to intermediaries that a particular value was intentionally sent as a literal. An intermediary MUST NOT re-encode a value that uses a literal representation with the 'N' bit set with another representation that would index it.  If QPACK is used for re-encoding, a literal representation with the 'N' bit set MUST be used.  If HPACK is used for re-encoding, the never indexed literal representation (see Section 6.2.3 of RFC7541) MUST be used. The choice to mark that a header field should never be indexed depends on several factors.  Since QPACK doesn't protect against guessing an entire header field value, short or low-entropy values are more readily recovered by an adversary.  Therefore, an encoder might choose not to index values with low entropy. An encoder might also choose not to index values for header fields that are considered to be highly valuable or sensitive to recovery, such as the Cookie or Authorization header fields. On the contrary, an encoder might prefer indexing values for header fields that have little or no value if they were exposed.  For instance, a User-Agent header field does not commonly vary between requests and is sent to any server.  In that case, confirmation that a particular User-Agent value has been used provides little value. Note that these criteria for deciding to use a never indexed literal representation will evolve over time as new attacks are discovered. 7.5. There is no currently known attack against a static Huffman encoding. A study has shown that using a static Huffman encoding table created an information leakage, however this same study concluded that an attacker could not take advantage of this information leakage to recover any meaningful amount of information (see PETAL). 7.6. An attacker can try to cause an endpoint to exhaust its memory. QPACK is designed to limit both the peak and stable amounts of memory allocated by an endpoint. The amount of memory used by the encoder is limited by the protocol using QPACK through the definition of the maximum size of the dynamic table, and the maximum number of blocking streams.  In HTTP/3, these values are controlled by the decoder through the settings parameters SETTINGS_QPACK_MAX_TABLE_CAPACITY and SETTINGS_QPACK_BLOCKED_STREAMS, respectively (see maximum-dynamic-table-capacity and blocked- streams).  The limit on the size of the dynamic table takes into account the size of the data stored in the dynamic table, plus a small allowance for overhead.  The limit on the number of blocked streams is only a proxy for the maximum amount of memory required by the decoder.  The actual maximum amount of memory will depend on how much memory the decoder uses to track each blocked stream. A decoder can limit the amount of state memory used for the dynamic table by setting an appropriate value for the maximum size of the dynamic table.  In HTTP/3, this is realized by setting an appropriate value for the SETTINGS_QPACK_MAX_TABLE_CAPACITY parameter.  An encoder can limit the amount of state memory it uses by signaling a lower dynamic table size than the decoder allows (see eviction). A decoder can limit the amount of state memory used for blocked streams by setting an appropriate value for the maximum number of blocked streams.  In HTTP/3, this is realized by setting an appropriate value for the QPACK_BLOCKED_STREAMS parameter.  An encoder can limit the amount of state memory by only using as many blocked streams as it wishes to support; no signaling to the decoder is requred. The amount of temporary memory consumed by an encoder or decoder can be limited by processing header fields sequentially.  A decoder implementation does not need to retain a complete list of header fields while decoding a header block.  An encoder implementation does not need to retain a complete list of header fields while encoding a header block if it is using a single-pass algorithm.  Note that it might be necessary for an application to retain a complete header list for other reasons; even if QPACK does not force this to occur, application constraints might make this necessary. </ins> While the negotiated limit on the dynamic table size accounts for much of the memory that can be consumed by a QPACK implementation,


new streams, reading only from the encoder stream, or closing the connection. <ins> 7.7. An implementation of QPACK needs to ensure that large values for integers, long encoding for integers, or long string literals do not create security weaknesses. An implementation has to set a limit for the values it accepts for integers, as well as for the encoded length (see prefixed-integers). In the same way, it has to set a limit to the length it accepts for string literals (see string-literals). </ins> 8. 8.1.


would be too large to fit in a packet, however receivers MAY also limit ACK frame size further to preserve space for other frames. <del> When discarding unacknowledged ACK Ranges, a receiver MUST retain the largest received packet number.  A receiver SHOULD retain ACK Ranges containing newly received packets or higher-numbered packets. </del> <ins> A receiver MUST retain an ACK Range unless it can ensure that it will not subsequently accept packets with numbers in that range. Maintaining a minimum packet number that increases as ranges are discarded is one way to achieve this with minimal state. Receivers can discard all ACK Ranges, but they MUST retain the largest packet number that has been successfully processed as that is used to recover packet numbers from subsequent packets; see packet- encoding. A receiver SHOULD include an ACK Range containing the largest received packet number in every ACK frame.  The Largest Acknowledged field is used in ECN validation at a sender and including a lower value than what was included in a previous ACK frame could cause ECN to be unnecessarily disabled; see ecn-validation. </ins> A receiver that sends only non-ack-eliciting packets, such as ACK frames, might not receive an acknowledgement for a long period of


21.12.1. The QUIC handshake incorporates the TLS 1.3 handshake and enjoys the <del> cryptographic properties described in Appendix E.1 of TLS13. </del> <ins> cryptographic properties described in Appendix E.1 of TLS13.  Many of the security properties of QUIC depend on the TLS handshake providing these properties.  Any attack on the TLS handshake could affect QUIC. </ins> <del> In addition to those properties, the handshake is intended to provide some defense against DoS attacks on the handshake, as described below. </del> <ins> Any attack on the TLS handshake that compromises the secrecy or uniqueness of session keys affects other security guarantees provided by QUIC that depends on these keys.  For instance, migration (migration) depends on the efficacy of confidentiality protections, both for the negotiation of keys using the TLS handshake and for QUIC packet protection, to avoid linkability across network paths. An attack on the integrity of the TLS handshake might allow an attacker to affect the selection of application protocol or QUIC version. In addition to the properties provided by TLS, the QUIC handshake provides some defense against DoS attacks on the handshake. </ins> 21.12.1.1.


packets being encrypted with per-version keys and the Handshake and later packets being encrypted with keys derived from the TLS key exchange.  Further, parameter negotiation is folded into the TLS <del> transcript and thus provides the same security guarantees as ordinary TLS negotiation.  Thus, an attacker can observe the client's transport parameters (as long as it knows the version-specific salt) </del> <ins> transcript and thus provides the same integrity guarantees as ordinary TLS negotiation.  An attacker can observe the client's transport parameters (as long as it knows the version-specific keys) </ins> but cannot observe the server's transport parameters and cannot influence parameter negotiation.


6.2.3. <del> Stream types of the format "0x1f * N + 0x21" for integer values of N are reserved to exercise the requirement that unknown types be ignored.  These streams have no semantics, and can be sent when application-layer padding is desired.  They MAY also be sent on </del> <ins> Stream types of the format "0x1f * N + 0x21" for non-negative integer values of N are reserved to exercise the requirement that unknown types be ignored.  These streams have no semantics, and can be sent when application-layer padding is desired.  They MAY also be sent on </ins> connections where no data is currently being transferred.  Endpoints MUST NOT consider these streams to have any meaning upon receipt.


The default value is unlimited.  See header-formatting for usage. <del> Setting identifiers of the format "0x1f * N + 0x21" for integer values of N are reserved to exercise the requirement that unknown identifiers be ignored.  Such settings have no defined meaning. Endpoints SHOULD include at least one such setting in their SETTINGS frame.  Endpoints MUST NOT consider such settings to have any meaning upon receipt. </del> <ins> Setting identifiers of the format "0x1f * N + 0x21" for non-negative integer values of N are reserved to exercise the requirement that unknown identifiers be ignored.  Such settings have no defined meaning.  Endpoints SHOULD include at least one such setting in their SETTINGS frame.  Endpoints MUST NOT consider such settings to have any meaning upon receipt. </ins> Because the setting has no defined meaning, the value of the setting can be any value the implementation selects.


7.2.8. <del> Frame types of the format "0x1f * N + 0x21" for integer values of N are reserved to exercise the requirement that unknown types be ignored (extensions).  These frames have no semantics, and can be sent on any open stream when application-layer padding is desired. They MAY also be sent on connections where no data is currently being transferred.  Endpoints MUST NOT consider these frames to have any meaning upon receipt. </del> <ins> Frame types of the format "0x1f * N + 0x21" for non-negative integer values of N are reserved to exercise the requirement that unknown types be ignored (extensions).  These frames have no semantics, and can be sent on any open stream when application-layer padding is desired.  They MAY also be sent on connections where no data is currently being transferred.  Endpoints MUST NOT consider these frames to have any meaning upon receipt. </ins> The payload and length of the frames are selected in any manner the implementation chooses.