diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index fcbcd69111..afde50ef73 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -895,7 +895,29 @@ keeping track of missing packet numbers. # Packet Protection {#packet-protection} As with TLS over TCP, QUIC protects packets with keys derived from the TLS -handshake, using the AEAD algorithm negotiated by TLS. +handshake, using the AEAD algorithm {{!AEAD}} negotiated by TLS. + +QUIC packets have varying protections depending on their type: + +* Version Negotiation packets have no cryptographic protection. + +* Retry packets use AEAD_AES_128_GCM to provide protection against accidental + modification or insertion by off-path adversaries; see + {{retry-integrity}}. + +* Initial packets use AEAD_AES_128_GCM with keys derived from the Destination + Connection ID field of the first Initial packet sent by the client; see + {{initial-secrets}}. + +* All other packets have strong cryptographic protections for confidentiality + and integrity, using keys and algorithms negotiated by TLS. + +This section describes how packet protection is applied to Handshake packets, +0-RTT packets, and 1-RTT packets. The same packet protection process is applied +to Initial packets. However, as it is trivial to determine the keys used for +Initial packets, these packets are not considered to have confidentiality or +integrity protection. Retry packets use a fixed key and so similarly lack +confidentiality and integrity protection. ## Packet Protection Keys {#protection-keys} @@ -923,13 +945,28 @@ KDF to produce the AEAD key; the label "quic iv" is used to derive the IV; see and TLS; see {{key-diversity}}. The KDF used for initial secrets is always the HKDF-Expand-Label function from -TLS 1.3 (see {{initial-secrets}}). +TLS 1.3; see {{initial-secrets}}. ## Initial Secrets {#initial-secrets} -Initial packets are protected with a secret derived from the Destination -Connection ID field from the client's Initial packet. Specifically: +Initial packets apply the packet protection process, but use a secret derived +from the Destination Connection ID field from the client's first Initial +packet. + +This secret is determined by using HKDF-Extract (see Section 2.2 of +{{!HKDF=RFC5869}}) with a salt of 0xafbfec289993d24c9e9786f19c6111e04390a899 +and a IKM of the Destination Connection ID field. This produces an intermediate +pseudorandom key (PRK) that is used to derive two separate secrets for sending +and receiving. + +The secret used by clients to construct Initial packets uses the PRK and the +label "client in" as input to the HKDF-Expand-Label function to produce a 32 +byte secret; packets constructed by the server use the same process with the +label "server in". The hash function for HKDF when deriving initial secrets +and keys is SHA-256 {{!SHA=DOI.10.6028/NIST.FIPS.180-4}}. + +This process in pseudocode is: ~~~ initial_salt = 0xafbfec289993d24c9e9786f19c6111e04390a899 @@ -944,24 +981,20 @@ server_initial_secret = HKDF-Expand-Label(initial_secret, Hash.length) ~~~ -The hash function for HKDF when deriving initial secrets and keys is SHA-256 -{{!SHA=DOI.10.6028/NIST.FIPS.180-4}}. - The connection ID used with HKDF-Expand-Label is the Destination Connection ID in the Initial packet sent by the client. This will be a randomly-selected value unless the client creates the Initial packet after receiving a Retry packet, where the Destination Connection ID is selected by the server. -The value of initial_salt is a 20-byte sequence shown in the figure 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 version of QUIC from seeing or -modifying the contents of packets from future versions. +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 +recognizes only one version of QUIC from seeing or modifying the contents of +packets from future versions. 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 TLS 1.3. -The secrets used for protecting Initial packets change when a server sends a +The secrets used for constructing Initial packets change when a server sends a Retry packet to use the connection ID value selected by the server. The secrets do not change when a client changes the Destination Connection ID it uses in response to an Initial packet from the server. @@ -974,7 +1007,7 @@ Note: that the server received its packet; the client has to rely on the exchange that included the Retry packet for that property. -{{test-vectors}} contains test vectors for packet encryption. +{{test-vectors}} contains sample Initial packets. ## AEAD Usage {#aead} @@ -984,19 +1017,6 @@ used for QUIC packet protection is the AEAD that is negotiated for use with the TLS connection. For example, if TLS is using the TLS_AES_128_GCM_SHA256 cipher suite, the AEAD_AES_128_GCM function is used. -Packets are protected prior to applying header protection ({{header-protect}}). -The unprotected packet header is part of the associated data (A). When removing -packet protection, an endpoint first removes the header protection. - -All QUIC packets other than Version Negotiation are protected with an AEAD -algorithm ({{!AEAD}}). Prior to establishing a shared secret, packets are -protected with AEAD_AES_128_GCM. Retry packets use the AEAD for integrity -protection only, as described in {{retry-integrity}}. Initial packets use a key -derived from the Destination Connection ID in the client's first Initial packet; -see {{initial-secrets}}. This provides protection against off-path attackers -and robustness against QUIC-version-unaware middleboxes, but not against on-path -attackers. - QUIC can use any of the cipher suites defined in {{!TLS13}} with the exception of TLS_AES_128_CCM_8_SHA256. A cipher suite MUST NOT be negotiated unless a header protection scheme is defined for the cipher suite. This document defines @@ -1010,6 +1030,11 @@ Note: does not support, or it would be impossible to deploy a new cipher suite. This also applies to TLS_AES_128_CCM_8_SHA256. +When constructing packets, the AEAD function is applied prior to applying +header protection; see {{header-protect}}. The unprotected packet header is part +of the associated data (A). When processing packets, an endpoint first +removes the header protection. + The key and IV for the packet are computed as described in {{protection-keys}}. The nonce, N, is formed by combining the packet protection IV with the packet number. The 62 bits of the reconstructed QUIC packet number in network byte diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 0a8e9a81a7..697267919d 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1175,10 +1175,11 @@ discarded if they indicate a different protocol version than that of the connection, or if the removal of packet protection is unsuccessful once the expected keys are available. -Invalid packets without packet protection, such as Initial, Retry, or Version -Negotiation, MAY be discarded. An endpoint MUST generate a connection error if -processing of the contents of these packets prior to discovering an error -resulted in changes to the state of a connection that cannot be reverted. +Invalid packets that lack strong integrity protection, such as Initial, Retry, +or Version Negotiation, MAY be discarded. An endpoint MUST generate a +connection error if processing the contents of these packets prior to +discovering an error resulted in changes to connection state that +cannot be reverted. ### Client Packet Handling {#client-pkt-handling} @@ -3157,30 +3158,35 @@ after a connection is established and 1-RTT keys are available; see ## Protected Packets {#packet-protected} -All QUIC packets except Version Negotiation packets use authenticated encryption -with associated data (AEAD) {{!RFC5116}} to provide confidentiality and -integrity protection. Retry packets use AEAD to provide integrity protection. -Details of packet protection are found in {{QUIC-TLS}}; this section includes an -overview of the process. +QUIC packets have different levels of cryptographic protection based on the +type of packet. Details of packet protection are found in {{QUIC-TLS}}; this +section includes an overview of the protections that are provided. -Initial packets are protected using keys that are statically derived. This -packet protection is not effective confidentiality protection. Initial -protection only exists to ensure that the sender of the packet is on the network -path. Any entity that receives the Initial packet from a client can recover the -keys necessary to remove packet protection or to generate packets that will be -successfully authenticated. +Version Negotiation packets have no cryptographic protection; see +{{QUIC-INVARIANTS}}. + +Retry packets use an authenticated encryption with associated data function +(AEAD; {{?AEAD=RFC5116}}) to protect against accidental modification. + +Initial packets use an AEAD, the keys for which are derived using a value that +is visible on the wire. Initial packets therefore do not have effective +confidentiality protection. Initial protection exists to ensure that the sender +of the packet is on the network path. Any entity that receives an Initial packet +from a client can recover the keys that will allow them to both read the +contents of the packet and generate Initial packets that will be successfully +authenticated at either endpoint. All other packets are protected with keys derived from the cryptographic -handshake. The type of the packet from the long header or key phase from the -short header are used to identify which encryption keys are used. Packets -protected with 0-RTT and 1-RTT keys are expected to have confidentiality and -data origin authentication; the cryptographic handshake ensures that only the -communicating endpoints receive the corresponding keys. - -The packet number field contains a packet number, which has additional -confidentiality protection that is applied after packet protection is applied; -see {{QUIC-TLS}} for details. The underlying packet number increases with each -packet sent in a given packet number space; see {{packet-numbers}} for details. +handshake. The cryptographic handshake ensures that only the communicating +endpoints receive the corresponding keys for Handshake, 0-RTT, and 1-RTT +packets. Packets protected with 0-RTT and 1-RTT keys have strong +confidentiality and integrity protection. + +The Packet Number field that appears in some packet types has alternative +confidentiality protection that is applied as part of header protection; see +Section 5.4 of {{QUIC-TLS}} for details. The underlying packet number increases +with each packet sent in a given packet number space; see {{packet-numbers}} for +details. ## Coalescing Packets {#packet-coalesce}