Mozilla

martin.thomson@gmail.com

Google

rch@google.com

This document describes how Transport Layer Security (TLS) can be used to secure QUIC.

QUIC provides a multiplexed transport for HTTP semantics that provides several key advantages over HTTP/1.1 or HTTP/2 over TCP . This document describes how QUIC can be secured using Transport Layer Security (TLS) version 1.3 . TLS 1.3 provides critical latency improvements for connection establishment over previous versions. Absent packet loss, most new connections can be established and secured within a single round trip; on subsequent connections between the same client and server, the client can often send application data immediately, that is, zero round trip setup. This document describes how the standardized TLS 1.3 can act a security component of QUIC. The same design could work for TLS 1.2, though few of the benefits QUIC provides would be realized due to the handshake latency in versions of TLS prior to 1.3.

The words “MUST”, “MUST NOT”, “SHOULD”, and “MAY” are used in this document. It’s not shouting; when they are capitalized, they have the special meaning defined in .

QUIC can be separated into several modules: The basic frame envelope describes the common packet layout. This layer includes connection identification, version negotiation, and includes markers that allow the framing and public reset to be identified. The public reset is an unprotected packet that allows an intermediary (an entity that is not part of the security context) to request the termination of a QUIC connection. Version negotiation frames are used to agree on a common version of QUIC to use. Framing comprises most of the QUIC protocol. Framing provides a number of different types of frame, each with a specific purpose. Framing supports frames for both congestion management and stream multiplexing. Framing additionally provides a liveness testing capability (the PING frame). Encryption provides confidentiality and integrity protection for frames. All frames are protected based on keying material derived from the TLS connection running on stream 1. Prior to this, data is protected with the 0-RTT keys. Multiplexed streams are the primary payload of QUIC. These provide reliable, in-order delivery of data and are used to carry the encryption handshake and transport parameters (stream 1), HTTP header fields (stream 3), and HTTP requests and responses. Frames for managing multiplexing include those for creating and destroying streams as well as flow control and priority frames. Congestion management includes packet acknowledgment and other signal required to ensure effective use of available link capacity. A complete TLS connection is run on stream 1. This includes the entire TLS record layer. As the TLS connection reaches certain states, keying material is provided to the QUIC encryption layer for protecting the remainder of the QUIC traffic. HTTP mapping provides an adaptation to HTTP that is based on HTTP/2. The relative relationship of these components are pictorally represented in .

This document defines the cryptographic parts of QUIC. This includes the handshake messages that are exchanged on stream 1, plus the record protection that is used to encrypt and authenticate all other frames.

TLS 1.3 provides two basic handshake modes of interest to QUIC: A full handshake in which the client is able to send application data after one round trip and the server immediately after receiving the first message from the client. A 0-RTT handshake in which the client uses information about the server to send immediately. This data can be replayed by an attacker so it MUST NOT carry a self-contained trigger for any non-idempotent action. A simplified TLS 1.3 handshake with 0-RTT application data is shown in , see for more options and details.

ServerHello {EncryptedExtensions} {ServerConfiguration} {Certificate} {CertificateVerify} {Finished} <-------- [Application Data] {Finished} --------> [Application Data] <-------> [Application Data] ]]>

Two additional variations on this basic handshake exchange are relevant to this document: The server can respond to a ClientHello with a HelloRetryRequest, which adds an additional round trip prior to the basic exchange. This is needed if the server wishes to request a different key exchange key from the client. HelloRetryRequest is also used to verify that the client is correctly able to receive packets on the address it claims to have (see ). A pre-shared key mode can be used for subsequent handshakes to avoid public key operations. This is the basis for 0-RTT data, even if the remainder of the connection is protected by a new Diffie-Hellman exchange.

QUIC completes its cryptographic handshake on stream 1, which means that the negotiation of keying material happens after the QUIC protocol has started. This simplifies the use of TLS since QUIC is able to ensure that the TLS handshake packets are delivered reliably and in order. QUIC Stream 1 carries a complete TLS connection. This includes the TLS record layer in its entirety. QUIC provides for reliable and in-order delivery of the TLS handshake messages on this stream. Prior to the completion of the TLS handshake, QUIC frames can be exchanged. However, these frames are not authenticated or confidentiality protected. covers some of the implications of this design and limitations on QUIC operation during this phase. Once complete, QUIC frames are protected using QUIC record protection, see .

The integration of QUIC with a TLS handshake is shown in more detail in . QUIC STREAM frames on stream 1 carry the TLS handshake. QUIC is responsible for ensuring that the handshake packets are re-sent in case of loss and that they can be ordered correctly.

: ClientHello + QUIC Setup Parameters --------> 0-RTT Key -> @B @B QUIC STREAM Frame(s) <1>: (Finished) Replayable QUIC Frames --------> QUIC STREAM Frame <1>: @B/A ServerHello {Handshake Messages} <-------- 1-RTT Key -> @C QUIC Frames @C <-------- @B QUIC STREAM Frame(s) <1>: (end_of_early_data <1>) {Finished} --------> @C QUIC Frames <-------> QUIC Frames @C ]]>

In , symbols mean: ”<” and “>” enclose stream numbers. ”@” indicates the key phase that is currently used for protecting QUIC packets. ”(“ and “)” enclose messages that are protected with TLS 0-RTT handshake or application keys. ”{“ and “}” enclose messages that are protected by the TLS Handshake keys. If 0-RTT is not possible, then the client does not send frames protected by the 0-RTT key (@B). The only key transition on the client is from cleartext (@A) to 1-RTT protection (@C). If 0-RTT data is not accepted by the server, then the server sends its handshake messages without protection (@A). The client still transitions from @A to @B, but it can stop sending 0-RTT data and progress immediately to 1-RTT data when it receives a cleartext ServerHello.

QUIC provides a record protection layer that is responsible for authenticated encryption of packets. The record protection layer uses keys provided by the TLS connection and authenticated encryption to provide confidentiality and integrity protection for the content of packets. Different keys are used for QUIC and TLS record protection. Having separate QUIC and TLS record protection means that TLS records can be protected by two different keys. This redundancy is maintained for the sake of simplicity.

The transition to use of a new QUIC key occurs immediately after sending the TLS handshake messages that produced the key transition. Every time that a new set of keys is used for protecting outbound messages, the KEY_PHASE bit in the public flags is toggled. The KEY_PHASE bit on unencrypted messages is 0. The KEY_PHASE bit on the public flags is the most significant bit (0x80). The KEY_PHASE bit allows a recipient to detect a change in keying material without needing to receive the message that triggers the change. This avoids head-of-line blocking around transitions between keys without relying on trial decryption. The following transitions are defined: The client transitions to using 0-RTT keys after sending the ClientHello. This causes the KEY_PHASE bit on packets sent by the client to be set to 1. The server transitions to using 0-RTT keys before sending the ServerHello, but only if the early data from the client is accepted. This transition causes the KEY_PHASE bit on packets sent by the server to be set to 1. If the server rejects 0-RTT data, the server’s handshake messages are sent without QUIC-level record protection with a KEY_PHASE of 0. TLS handshake messages will still be protected by TLS record protection based on the TLS handshake traffic keys. The server transitions to using 1-RTT keys after sending its Finished message. This causes the KEY_PHASE bit to be set to 0 if early data was accepted, and 1 if the server rejected early data. The client transitions to 1-RTT keys after sending its Finished message. Subsequent messages from the client will then have a KEY_PHASE of 0 if 0-RTT data was sent, and 1 otherwise. Both peers start sending messages protected by a new key immediately after sending a TLS KeyUpdate message. The value of the KEY_PHASE bit is changed each time. At each point, both keying material (see ) and the AEAD function used by TLS is interchanged with the values that are currently in use for protecting outbound packets. Once a change of keys has been made, packets with higher sequence numbers MUST use the new keying material until a newer set of keys (and AEAD) are used. The exception to this is that retransmissions of TLS handshake packets MUST use the keys that they were originally protected with. Once a packet protected by a new key has been received, a recipient SHOULD retain the previous keys for a short period. Retaining old keys allows the recipient to decode reordered packets around a change in keys. Keys SHOULD be discarded when an endpoints has received all packets with sequence numbers lower than the lowest sequence number used for the new key, or when it determines that reordering of those packets is unlikely. 0-RTT keys SHOULD be retained until the handshake is complete. The KEY_PHASE bit does not directly indicate which keys are in use. Depending on whether 0-RTT data was sent and accepted, packets protected with keys derived from the same secret might be marked with different KEY_PHASE values.

TLS handshake messages need to be retransmitted with the same level of cryptographic protection that was originally used to protect them. Newer keys cannot be used to protect QUIC packets that carry TLS messages. A client would be unable to decrypt retransmissions of a server’s handshake messages that are protected using the 1-RTT keys, since the calculation of the application data keys depends on the contents of the handshake messages. This restriction means the creation of an exception to the requirement to always use new keys for sending once they are available. A server MUST mark the retransmitted handshake messages with the same KEY_PHASE as the original messages to allow a recipient to distinguish the messages.

Once the TLS handshake is complete, the KEY_PHASE bit allows for the processing of messages without having to receive the TLS KeyUpdate message that triggers the key update. This allows endpoints to start using updated keys immediately without the concern that a lost KeyUpdate will cause their messages to be indecipherable to their peer.. An endpoint MUST NOT initiate more than one key update at a time. A new key update cannot be sent until the endpoint has received a matching KeyUpdate message from its peer; or, if the endpoint did not initiate the original key update, it has received an acknowledgment of its own KeyUpdate. This ensures that there are at most two keys to distinguish between at any one time, for which the KEY_PHASE bit is sufficient.

@N @N QUIC Frames --------> KeyUpdate @N <-------- -- Initiating Peer can initiate another KeyUpdate -- @N Acknowledgment --------> -- Responding Peer can initiate another KeyUpdate -- ]]>

As shown in and , there is never a situation where there are more than two different sets of keying material that might be received by a peer. A server cannot initiate a key update until it has received the client’s Finished message. Otherwise, packets protected by the updated keys could be confused for retransmissions of handshake messages. A client cannot initiate a key update until it has received an acknowledgment that its Finished message has been received. This models the key changes in the handshake as a key update initiated by the server, with the Finished message in the place of KeyUpdate.

The following table shows QUIC keys, when they are generated and the TLS secret from which they are derived: Key TLS Secret Phase 0-RTT early_traffic_secret “QUIC 0-RTT key expansion” 1-RTT traffic_secret_N “QUIC 1-RTT key expansion” 0-RTT keys are those keys that are used in resumed connections prior to the completion of the TLS handshake. Data sent using 0-RTT keys might be replayed and so has some restrictions on its use, see . 0-RTT keys are used after sending or receiving a ClientHello. 1-RTT keys are used after the TLS handshake completes. There are potentially multiple sets of 1-RTT keys; new 1-RTT keys are created by sending a TLS KeyUpdate message. 1-RTT keys are used after sending a Finished or KeyUpdate message. The complete key expansion uses the same process for key expansion as defined in Section 7.3 of . For example, the Client Write Key for the data sent immediately after sending the TLS Finished message is:

This results in a label input to HKDF that includes a two-octet length field, the string “TLS 1.3, QUIC 1-RTT key expansion, client write key” and a zero octet. The QUIC record protection initially starts without keying material. When the TLS state machine produces the corresponding secret, new keys are generated from the TLS connection and used to protect the QUIC record protection. The Authentication Encryption with Associated Data (AEAD) function used is the same one that is negotiated for use with the TLS connection. For example, if TLS is using the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, the AEAD_AES_128_GCM function is used.

Regular QUIC packets are protected by an AEAD . Version negotiation and public reset packets are not protected. Once TLS has provided a key, the contents of regular QUIC packets immediately after any TLS messages have been sent are protected by the AEAD selected by TLS. The key, K, for the AEAD is either the Client Write Key or the Server Write Key, derived as defined in . The nonce, N, for the AEAD is formed by combining either the Client Write IV or Server Write IV with the sequence numbers. The 48 bits of the reconstructed QUIC sequence number (see ) in network byte order is left-padded with zeros to the N_MAX parameter of the AEAD (see Section 4 of ). The exclusive OR of the padded sequence number and the IV forms the AEAD nonce. The associated data, A, for the AEAD is an empty sequence. The input plaintext, P, for the AEAD is the contents of the QUIC frame following the packet number, as described in The output ciphertext, C, of the AEAD is transmitted in place of P. Prior to TLS providing keys, no record protection is performed and the plaintext, P, is transmitted unmodified. QUIC defined a null-encryption that had an additional, hash-based checksum for cleartext packets. This might be added here, but it is more complex.

Each peer maintains a 48-bit sequence number that is incremented with every packet that is sent, including retransmissions. The least significant 8-, 16-, 32-, or 48-bits of this number is encoded in the QUIC sequence number field in every packet. A receiver maintains the same values, but recovers values based on the packets it receives. This is based on the sequence number of packets that it has received. A simple scheme predicts the receive sequence number of an incoming packet by incrementing the sequence number of the most recent packet to be successfully decrypted by one and expecting the sequence number to be within a range centered on that value. A more sophisticated algorithm can almost double the search space by checking backwards from the most recent sequence for a received (or abandoned) packet. If a packet was received, then the packet contains a sequence number that is greater than the most recent sequence number. If no such packet was found, the number is assumed to be in the smaller window centered on the next sequence number, as in the simpler scheme. QUIC has a single, contiguous sequence number space. In comparison, TLS restarts its sequence number each time that record protection keys are changed. The sequence number restart in TLS ensures that a compromise of the current traffic keys does not allow an attacker to truncate the data that is sent after a key update by sending additional packets under the old key (causing new packets to be discarded). QUIC does not assume a reliable transport and is therefore required to handle attacks where packets are dropped in other ways. TLS maintains a separate sequence number that is used for record protection on the connection that is hosted on stream 1. This sequence number is reset according to the rules in the TLS protocol.

Implementations MUST NOT exchange data on any stream other than stream 1 prior to the completion of the TLS handshake. However, QUIC requires the use of several types of frame for managing loss detection and recovery. In addition, it might be useful to use the data acquired during the exchange of unauthenticated messages for congestion management. This section generally only applies to TLS handshake messages from both peers and acknowledgments of the packets carrying those messages. In many cases, the need for servers to provide acknowledgments is minimal, since the messages that clients send are small and implicitly acknowledged by the server’s responses. The actions that a peer takes as a result of receiving an unauthenticated packet needs to be limited. In particular, state established by these packets cannot be retained once record protection commences. There are several approaches possible for dealing with unauthenticated packets prior to handshake completion: discard and ignore them use them, but reset any state that is established once the handshake completes use them and authenticate them afterwards; failing the handshake if they can’t be authenticated save them and use them when they can be properly authenticated treat them as a fatal error Different strategies are appropriate for different types of data. This document proposes that all strategies are possible depending on the type of message. Transport parameters and options are made usable and authenticated as part of the TLS handshake (see ). Most unprotected messages are treated as fatal errors when received except for the small number necessary to permit the handshake to complete (see ). Protected packets can either be discarded or saved and later used (see ).

This section describes the handling of messages that are sent and received prior to the completion of the TLS handshake. Sending and receiving unprotected messages is hazardous. Unless expressly permitted, receipt of an unprotected message of any kind MUST be treated as a fatal error.

STREAM frames for stream 1 are permitted. These carry the TLS handshake messages. Receiving unprotected STREAM frames for other streams MUST be treated as a fatal error.

ACK frames are permitted prior to the handshake being complete. Information learned from ACK frames cannot be entirely relied upon, since an attacker is able to inject these packets. Timing and packet retransmission information from ACK frames is critical to the functioning of the protocol, but these frames might be spoofed or altered. Endpoints MUST NOT use an unprotected ACK frame to acknowledge data that was protected by 0-RTT or 1-RTT keys. An endpoint MUST ignore an unprotected ACK frame if it claims to acknowledge data that was protected data. Such an acknowledgement can only serve as a denial of service, since an endpoint that can read protected data is always permitted to send protected data. An endpoint SHOULD use data from unprotected or 0-RTT-protected ACK frames only during the initial handshake and while they have insufficient information from 1-RTT-protected ACK frames. Once sufficient information has been obtained from protected messages, information obtained from less reliable sources can be discarded.

WINDOW_UPDATE frames MUST NOT be sent unprotected. Though data is exchanged on stream 1, the initial flow control window is is sufficiently large to allow the TLS handshake to complete. This limits the maximum size of the TLS handshake and would prevent a server or client from using an abnormally large certificate chain. Stream 1 is exempt from the connection-level flow control window.

Accepting unprotected - specifically unauthenticated - packets presents a denial of service risk to endpoints. An attacker that is able to inject unprotected packets can cause a recipient to drop even protected packets with a matching sequence number. The spurious packet shadows the genuine packet, causing the genuine packet to be ignored as redundant. Once the TLS handshake is complete, both peers MUST ignore unprotected packets. The handshake is complete when the server receives a client’s Finished message and when a client receives an acknowledgement that their Finished message was received. From that point onward, unprotected messages can be safely dropped. Note that the client could retransmit its Finished message to the server, so the server cannot reject such a message. Since only TLS handshake packets and acknowledgments are sent in the clear, an attacker is able to force implementations to rely on retransmission for packets that are lost or shadowed. Thus, an attacker that intends to deny service to an endpoint has to drop or shadow protected packets in order to ensure that their victim continues to accept unprotected packets. The ability to shadow packets means that an attacker does not need to be on path. This would not be an issue if QUIC had a randomized starting sequence number. If we choose to randomize, we fix this problem and reduce the denial of service exposure to on-path attackers. The only possible problem is in authenticating the initial value, so that peers can be sure that they haven’t missed an initial message. In addition to denying endpoints messages, an attacker to generate packets that cause no state change in a recipient. See for a discussion of these risks. To avoid receiving TLS packets that contain no useful data, a TLS implementation MUST reject empty TLS handshake records and any record that is not permitted by the TLS state machine. Any TLS application data or alerts - other than a single end_of_early_data at the appropriate time - that is received prior to the end of the handshake MUST be treated as a fatal error.

If 0-RTT keys are available, the lack of replay protection means that restrictions on their use are necessary to avoid replay attacks on the protocol. A client MUST only use 0-RTT keys to protect data that is idempotent. A client MAY wish to apply additional restrictions on what data it sends prior to the completion of the TLS handshake. A client otherwise treats 0-RTT keys as equivalent to 1-RTT keys. A client that receives an indication that its 0-RTT data has been accepted by a server can send 0-RTT data until it receives all of the server’s handshake messages. A client SHOULD stop sending 0-RTT data if it receives an indication that 0-RTT data has been rejected. In addition to a ServerHello without an early_data extension, an unprotected handshake message with a KEY_PHASE bit set to 0 indicates that 0-RTT data has been rejected. A client SHOULD send its end_of_early_data alert only after it has received all of the server’s handshake messages. Alternatively phrased, a client is encouraged to use 0-RTT keys until 1-RTT keys become available. This prevents stalling of the connection and allows the client to send continuously. A server MUST NOT use 0-RTT keys to protect anything other than TLS handshake messages. Servers therefore treat packets protected with 0-RTT keys as equivalent to unprotected packets in determining what is permissible to send. A server protects handshake messages using the 0-RTT key if it decides to accept a 0-RTT key. A server MUST still include the early_data extension in its ServerHello message. This restriction prevents a server from responding to a request using frames protected by the 0-RTT keys. This ensures that all application data from the server are always protected with keys that have forward secrecy. However, this results in head-of-line blocking at the client because server responses cannot be decrypted until all the server’s handshake messages are received by the client.

Due to reordering and loss, protected packets might be received by an endpoint before the final handshake messages are received. If these can be decrypted successfully, such packets MAY be stored and used once the handshake is complete. Unless expressly permitted below, encrypted packets MUST NOT be used prior to completing the TLS handshake, in particular the receipt of a valid Finished message and any authentication of the peer. If packets are processed prior to completion of the handshake, an attacker might use the willingness of an implementation to use these packets to mount attacks. TLS handshake messages are covered by record protection during the handshake, once key agreement has completed. This means that protected messages need to be decrypted to determine if they are TLS handshake messages or not. Similarly, ACK and WINDOW_UPDATE frames might be needed to successfully complete the TLS handshake. Any timestamps present in ACK frames MUST be ignored rather than causing a fatal error. Timestamps on protected frames MAY be saved and used once the TLS handshake completes successfully. An endpoint MAY save the last protected WINDOW_UPDATE frame it receives for each stream and apply the values once the TLS handshake completes. Failing to do this might result in temporary stalling of affected streams.

QUIC uses the TLS handshake for more than just negotiation of cryptographic parameters. The TLS handshake validates protocol version selection, provides preliminary values for QUIC transport parameters, and allows a server to perform return routeability checks on clients.

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 during the handshake, though it means that such a downgrade causes a handshake failure. Protocols that use the QUIC transport MUST use Application Layer Protocol Negotiation (ALPN) . The ALPN identifier for the protocol MUST be specific to the QUIC version that it operates over. When constructing a ClientHello, clients MUST include a list of all the ALPN identifiers that they support, regardless of whether the QUIC version that they have currently selected supports that protocol. Servers SHOULD select an application protocol based solely on the information in the ClientHello, not using the QUIC version that the client has selected. If the protocol that is selected is not supported with the QUIC version that is in use, the server MUST either send a QUIC version negotiation packet if this is possible, or fail the connection otherwise.

QUIC defines an extension for use with TLS. That extension defines transport-related parameters. This provides integrity protection for these values. Including these in the TLS handshake also make the values that a client sets available to a server one-round trip earlier than parameters that are carried in QUIC frames. This document does not define that extension.

QUIC implementations describe a source address token. This is an opaque blob that a server might provide to clients when they first use a given source address. The client returns this token in subsequent messages as a return routeability check. That is, the client returns this token to prove that it is able to receive packets at the source address that it claims. This prevents the server from being used in packet reflection attacks (see ). A source address token is opaque and consumed only by the server. Therefore it can be included in the TLS 1.3 pre-shared key identifier for 0-RTT handshakes. Servers that use 0-RTT are advised to provide new pre-shared key identifiers after every handshake to avoid linkability of connections by passive observers. Clients MUST use a new pre-shared key identifier for every connection that they initiate; if no pre-shared key identifier is available, then resumption is not possible. A server that is under load might include a source address token in the cookie extension of a HelloRetryRequest. (Note: the current version of TLS 1.3 does not include the ability to include a cookie in HelloRetryRequest.)

QUIC uses TLS without modification. Therefore, it is possible to use a pre-shared key that was obtained in a TLS connection over TCP to enable 0-RTT in QUIC. Similarly, QUIC can provide a pre-shared key that can be used to enable 0-RTT in TCP. All the restrictions on the use of 0-RTT apply, and the certificate MUST be considered valid for both connections, which will use different protocol stacks and could use different port numbers. For instance, HTTP/1.1 and HTTP/2 operate over TLS and TCP, whereas QUIC operates over UDP. Source address validation is not completely portable between different protocol stacks. Even if the source IP address remains constant, the port number is likely to be different. Packet reflection attacks are still possible in this situation, though the set of hosts that can initiate these attacks is greatly reduced. A server might choose to avoid source address validation for such a connection, or allow an increase to the amount of data that it sends toward the client without source validation.

There are likely to be some real clangers here eventually, but the current set of issues is well captured in the relevant sections of the main text. Never assume that because it isn’t in the security considerations section it doesn’t affect security. Most of this document does.

A small ClientHello that results in a large block of handshake messages from a server can be used in packet reflection attacks to amplify the traffic generated by an attacker. Certificate caching can reduce the size of the server’s handshake messages significantly. A client SHOULD also pad its ClientHello to at least 1024 octets (TODO: tune this value). A server is less likely to generate a packet reflection attack if the data it sends is a small multiple of the data it receives. A server SHOULD use a HelloRetryRequest if the size of the handshake messages it sends is likely to exceed the size of the ClientHello.

QUIC, TLS and HTTP/2 all contain a messages that have legitimate uses in some contexts, but that can be abused to cause a peer to expend processing resources without having any observable impact on the state of the connection. If processing is disproportionately large in comparison to the observable effects on bandwidth or state, then this could allow a malicious peer to exhaust processing capacity without consequence. QUIC prohibits the sending of empty STREAM frames unless they are marked with the FIN bit. This prevents STREAM frames from being sent that only waste effort. TLS records SHOULD always contain at least one octet of a handshake messages or alert. Records containing only padding are permitted during the handshake, but an excessive number might be used to generate unnecessary work. Once the TLS handshake is complete, endpoints SHOULD NOT send TLS application data records unless it is to hide the length of QUIC records. QUIC packet protection does not include any allowance for padding; padded TLS application data records can be used to mask the length of QUIC frames. While there are legitimate uses for some redundant packets, implementations SHOULD track redundant packets and treat excessive volumes of any non-productive packets as indicative of an attack.

This document has no IANA actions. Yet.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. QUIC (Quick UDP-based Internet Connection) is a multiplexed and secure transport protocol that runs on top of UDP. QUIC builds on past transport experience, and implements mechanisms that make it useful as a modern general-purpose transport protocol. Using UDP as the basis of QUIC is intended to address compatibility issues with legacy clients and middleboxes. QUIC authenticates all of its headers, preventing third parties from from changing them. QUIC encrypts most of its headers, thereby limiting protocol evolution to QUIC endpoints only. Therefore, middleboxes, in large part, are not required to be updated as new protocol versions are deployed. This document describes the core QUIC protocol, including the conceptual design, wire format, and mechanisms of the QUIC protocol for connection establishment, stream multiplexing, stream and connection- level flow control, and data reliability. Accompanying documents describe QUIC's loss recovery and congestion control, and the use of TLS1.3 for key negotiation. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations. Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. This memo describes a Transport Layer Security (TLS) extension that can be used to pad ClientHello messages to a desired size. Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA).This document defines an extension that allows a TLS client to inform a server of cached information, thereby enabling the server to omit already available information.

Christian Huitema’s knowledge of QUIC is far better than my own. This would be even more inaccurate and useless if not for his assistance. This document has variously benefited from a long series of discussions with Jana Iyengar, Adam Langley, Roberto Peon, Eric Rescorla, Ian Swett, and likely many others who are merely forgotten by a faulty meat computer.