diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 5cac329a32..b6250c708d 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -263,20 +263,20 @@ document: HelloRetryRequest is also used to verify that the client is correctly able to receive packets on the address it claims to have (see {{QUIC-TRANSPORT}}). - * A pre-shared key mode can be used for subsequent handshakes to - reduce the number of 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. + * A pre-shared key mode can be used for subsequent handshakes to reduce the + number of 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. # TLS Usage QUIC reserves stream 0 for a TLS connection. Stream 0 contains a complete TLS connection, which includes the TLS record layer. Other than the definition of a -QUIC-specific extension (see Section-TBD), TLS is unmodified for this use. This -means that TLS will apply confidentiality and integrity protection to its -records. In particular, TLS record protection is what provides confidentiality -protection for the TLS handshake messages sent by the server. +QUIC-specific extension (see {{quic_parameters}}), TLS is unmodified for this +use. This means that TLS will apply confidentiality and integrity protection to +its records. In particular, TLS record protection is what provides +confidentiality protection for the TLS handshake messages sent by the server. QUIC permits a client to send frames on streams starting from the first packet. The initial packet from a client contains a stream frame for stream 0 that @@ -330,17 +330,24 @@ ensures that TLS handshake messages are delivered in the correct order. In {{quic-tls-handshake}}, symbols mean: * "<" and ">" enclose stream numbers. -* "@" indicates the key phase that is currently used for protecting QUIC - packets. + +* "@" indicates the keys that are used for protecting the QUIC packet (C = + cleartext, with integrity only; 0 = 0-RTT keys; 1 = 1-RTT keys). + * "(" 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 attempted, then the client does not send packets protected by the 0-RTT key (@0). In that case, the only key transition on the client is from -unprotected packets (@C) to 1-RTT protection (@1), which happens after it sends +cleartext packets (@C) to 1-RTT protection (@1), which happens after it sends its final set of TLS handshake messages. +Note: the client uses two different types of cleartext packet during the +handshake. The Client Initial packet carries a TLS ClientHello message; the +remainder of the TLS handshake is carried in Client Cleartext packets. + The server sends TLS handshake messages without protection (@C). The server transitions from no protection (@C) to full 1-RTT protection (@1) after it sends the last of its handshake messages. @@ -897,9 +904,9 @@ during the handshake a new secret is exported from TLS and packet protection keys are derived from that secret. Every time that a new set of keys is used for protecting outbound packets, the -KEY_PHASE bit in the public flags is toggled. The exception is the transition -from 0-RTT keys to 1-RTT keys, where the presence of the version field and its -associated bit is used (see {{first-keys}}). +KEY_PHASE bit in the public flags is toggled. 0-RTT protected packets use the +QUIC long header, they do not use the KEY_PHASE bit to select the correct keys +(see {{first-keys}}). Once the connection is fully enabled, the KEY_PHASE bit allows a recipient to detect a change in keying material without necessarily needing to receive the @@ -907,7 +914,9 @@ first packet that triggered the change. An endpoint that notices a changed KEY_PHASE bit can update keys and decrypt the packet that contains the changed bit, see {{key-update}}. -The KEY_PHASE bit is the third bit of the public flags (0x04). +The KEY_PHASE bit is included as the 0x20 bit of the QUIC short header, or is +determined by the packet type from the long header (a type of 0x06 indicates a +key phase of 0, 0x07 indicates key phase 1). Transitions between keys during the handshake are complicated by the need to ensure that TLS handshake messages are sent with the correct packet protection. @@ -915,13 +924,12 @@ ensure that TLS handshake messages are sent with the correct packet protection. ## Packet Protection for the TLS Handshake {#cleartext-hs} -The initial exchange of packets are sent without protection. These packets are -marked with a KEY_PHASE of 0. +The initial exchange of packets are sent without protection. These packets use +a cleartext packet type. -TLS handshake messages MUST NOT be protected using QUIC packet protection. A -KEY_PHASE of 0 is used for all of these packets, even during retransmission. -The messages affected are all TLS handshake message up to the TLS Finished that -is sent by each endpoint. +TLS handshake messages MUST NOT be protected using QUIC packet protection. All +TLS handshake messages up to the TLS Finished message sent by either endpoint +use cleartext packets. Any TLS handshake messages that are sent after completing the TLS handshake do not need special packet protection rules. Packets containing these messages use @@ -930,7 +938,7 @@ retransmission). Like the client, a server MUST send retransmissions of its unprotected handshake messages or acknowledgments for unprotected handshake messages sent by the -client in unprotected packets (KEY_PHASE=0). +client in cleartext packets. ### Initial Key Transitions {#first-keys} @@ -938,29 +946,17 @@ client in unprotected packets (KEY_PHASE=0). Once the TLS handshake is complete, keying material is exported from TLS and QUIC packet protection commences. -Packets protected with 1-RTT keys have a KEY_PHASE bit set to 1. These packets -also have a VERSION bit set to 0. - -If the client sends 0-RTT data, it marks packets protected with 0-RTT keys with -a KEY_PHASE of 1 and a VERSION bit of 1. Setting the version bit means that all -packets also include the version field. The client retains the VERSION bit, but -reverts the KEY_PHASE bit for the packet that contains the TLS EndOfEarlyData -and Finished messages. - -The client clears the VERSION bit and sets the KEY_PHASE bit to 1 when it -transitions to using 1-RTT keys. +Packets protected with 1-RTT keys initially have a KEY_PHASE bit set to 0. This +bit inverts with each subsequent key update (see {{key-update}}). -Marking 0-RTT data with the both KEY_PHASE and VERSION bits ensures that the -server is able to identify these packets as 0-RTT data in case packets -containing TLS handshake message are lost or delayed. Including the version -also ensures that the packet format is known to the server in this case. +If the client sends 0-RTT data, it uses the 0-RTT packet type. The packet that +contains the TLS EndOfEarlyData and Finished messages are sent in cleartext +packets. -Using both KEY_PHASE and VERSION also ensures that the server is able to -distinguish between cleartext handshake packets (KEY_PHASE=0, VERSION=1), 0-RTT -protected packets (KEY_PHASE=1, VERSION=1), and 1-RTT protected packets -(KEY_PHASE=1, VERSION=0). Packets with all of these markings can arrive -concurrently, and being able to identify each cleanly ensures that the correct -packet protection keys can be selected and applied. +Using distinct packet types during the handshake for handshake messages, 0-RTT +data, and 1-RTT data ensures that the server is able to distinguish between the +different keys used to remove packet protection. All of these packets can +arrive concurrently at a server. A server might choose to retain 0-RTT packets that arrive before a TLS ClientHello. The server can then use those packets once the ClientHello @@ -971,8 +967,8 @@ packets that are saved might be necessary. The server transitions to using 1-RTT keys after sending its first flight of TLS handshake messages. From this point, the server protects all packets with 1-RTT -keys. Future packets are therefore protected with 1-RTT keys and marked with a -KEY_PHASE of 1. +keys. Future packets are therefore protected with 1-RTT keys. Initially, these +are marked with a KEY_PHASE of 0. ### Retransmission and Acknowledgment of Unprotected Packets @@ -982,23 +978,23 @@ exchange. The contents of these messages determines the keys used to protect later messages. If these handshake messages are included in packets that are protected with these keys, they will be indecipherable to the recipient. -Even though newer keys could be available when retranmitting, retransmissions of -these handshake messages MUST be sent in unprotected packets (with a KEY_PHASE -of 0). An endpoint MUST also generate ACK frames for these messages that are -sent in unprotected packets. +Even though newer keys could be available when retransmitting, retransmissions +of these handshake messages MUST be sent in cleartext packets. An endpoint +MUST generate ACK frames for these messages and send them in cleartext packets. A HelloRetryRequest handshake message might be used to reject an initial -ClientHello. A HelloRetryRequest handshake message and any second ClientHello -that is sent in response MUST also be sent without packet protection. This is -natural, because no new keying material will be available when these messages -need to be sent. Upon receipt of a HelloRetryRequest, a client SHOULD cease any +ClientHello. A HelloRetryRequest handshake message is sent in a Server +Stateless Retry packet; any second ClientHello that is sent in response uses a +Client Initial packet type. Neither packet is protected. This is natural, +because no new keying material will be available when these messages need to be +sent. Upon receipt of a HelloRetryRequest, a client SHOULD cease any transmission of 0-RTT data; 0-RTT data will only be discarded by any server that sends a HelloRetryRequest. -The KEY_PHASE and VERSION bits ensure that protected packets are clearly -distinguished from unprotected packets. Loss or reordering might cause -unprotected packets to arrive once 1-RTT keys are in use, unprotected packets -are easily distinguished from 1-RTT packets. +The packet type ensures that protected packets are clearly distinguished from +unprotected packets. Loss or reordering might cause unprotected packets to +arrive once 1-RTT keys are in use, unprotected packets are easily distinguished +from 1-RTT packets using the packet type. Once 1-RTT keys are available to an endpoint, it no longer needs the TLS handshake messages that are carried in unprotected packets. However, a server @@ -1392,8 +1388,8 @@ 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. +prior to the completion of the handshake, though it means that a downgrade +causes a handshake failure. TLS uses Application Layer Protocol Negotiation (ALPN) {{!RFC7301}} to select an application protocol. The application-layer protocol MAY restrict the QUIC @@ -1470,12 +1466,11 @@ by an attacker. Certificate caching {{?RFC7924}} can reduce the size of the server's handshake messages significantly. -QUIC requires that the packet containing a ClientHello be padded to the size of -the maximum transmission unit (MTU). A server is less likely to generate a -packet reflection attack if the data it sends is a small multiple of this size. -A server SHOULD use a HelloRetryRequest if the size of the handshake messages it -sends is likely to significantly exceed the size of the packet containing the -ClientHello. +QUIC requires that the packet containing a ClientHello be padded to a minimum +size. A server is less likely to generate a packet reflection attack if the +data it sends is a small multiple of this size. A server SHOULD use a +HelloRetryRequest if the size of the handshake messages it sends is likely to +significantly exceed the size of the packet containing the ClientHello. ## Peer Denial of Service {#useless} diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 16949d986b..595387edce 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -420,9 +420,9 @@ The following packet types are defined: | 03 | Server Stateless Retry | {{packet-server-stateless}} | | 04 | Server Cleartext | {{packet-server-cleartext}} | | 05 | Client Cleartext | {{packet-client-cleartext}} | -| 06 | 0-RTT Encrypted | {{packet-encrypted}} | -| 07 | 1-RTT Encrypted (key phase 0) | {{packet-encrypted}} | -| 08 | 1-RTT Encrypted (key phase 1) | {{packet-encrypted}} | +| 06 | 0-RTT Protected | {{packet-protected}} | +| 07 | 1-RTT Protected (key phase 0) | {{packet-protected}} | +| 08 | 1-RTT Protected (key phase 1) | {{packet-protected}} | | 09 | Public Reset | {{packet-public-reset}} | {: #long-packet-types title="Long Header Packet Types"} @@ -452,7 +452,7 @@ following sections. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Number (8/16/32) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Encrypted Payload (*) ... +| Protected Payload (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~~~ {: #fig-short-header title="Short Header Format"} @@ -492,7 +492,7 @@ Packet Number: : The length of the packet number field depends on the packet type. This field can be 1, 2 or 4 octets long depending on the short packet type. -Encrypted Payload: +Protected Payload: : Packets with a short header always include a 1-RTT protected payload. @@ -645,7 +645,7 @@ The connection ID field in a Client Cleartext packet contains a server-selected connection ID, see {{connection-id}}. The Client Cleartext packet includes a packet number that is one higher than the -last Client Initial, 0-RTT Encrypted or Client Cleartext packet that was sent. +last Client Initial, 0-RTT Protected or Client Cleartext packet that was sent. The packet number is incremented for each subsequent packet, see {{packet-numbers}}. @@ -653,7 +653,7 @@ The payload of this packet contains STREAM frames and could contain PADDING and ACK frames. -## Encrypted Packets {#packet-encrypted} +## Protected Packets {#packet-protected} Packets that are protected with 0-RTT keys are sent with long headers. Packets that are protected with 1-RTT keys MAY be sent with long headers. The different @@ -673,15 +673,14 @@ Packets protected with 1-RTT keys use a type octet of 0x87 for key phase 0 and phases. The connection ID field for these packet types MUST contain the value selected by the server, see {{connection-id}}. -The version field for encrypted packets is the current QUIC version. +The version field for protected packets is the current QUIC version. The packet number field contains a packet number, which increases with each packet sent, see {{packet-numbers}} for details. -The encrypted payload is both authenticated and encrypted using packet -protection keys. {{QUIC-TLS}} describes packet protection in detail. After -decryption, the plaintext consists of a sequence of frames, as described in -{{frames}}. +The payload is protected using authenticated encryption. {{QUIC-TLS}} describes +packet protection in detail. After decryption, the plaintext consists of a +sequence of frames, as described in {{frames}}. ## Public Reset Packet {#packet-public-reset} @@ -700,7 +699,7 @@ The connection ID and packet number of fields together contain octets 1 through connection ID on every packet, the Connection ID field is simply an echo of the client's Connection ID, and the Packet Number field includes an echo of the client's packet number. Depending on the client's packet number length it might -also include 0, 2, or 3 additional octets from the encrypted payload of the +also include 0, 2, or 3 additional octets from the protected payload of the client packet. The version field contains the current QUIC version. @@ -836,7 +835,7 @@ an unsupported version. # Frames and Frame Types {#frames} -The payload of cleartext packets and the plaintext after decryption of encrypted +The payload of cleartext packets and the plaintext after decryption of protected payloads consists of a sequence of frames, as shown in {{packet-frames}}. ~~~ @@ -852,9 +851,9 @@ payloads consists of a sequence of frames, as shown in {{packet-frames}}. | Frame N (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~ -{: #packet-frames title="Contents of Encrypted Payload"} +{: #packet-frames title="Contents of Protected Payload"} -Encrypted payloads MUST contain at least one frame, and MAY contain multiple +Protected payloads MUST contain at least one frame, and MAY contain multiple frames and multiple frame types. Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC packet @@ -2178,7 +2177,7 @@ in the GOAWAY frame can then be retried. The Path Maximum Transmission Unit (PTMU) is the maximum size of the entire IP header, UDP header, and UDP payload. The UDP payload includes the QUIC public -header, encrypted payload, and any authentication fields. +header, protected payload, and any authentication fields. All QUIC packets SHOULD be sized to fit within the estimated PMTU to avoid IP fragmentation or packet drops. To optimize bandwidth efficiency, endpoints @@ -3049,10 +3048,10 @@ sent, the connection can be aborted. The second mitigation is that the server can require that acknowledgments for sent packets match the encryption level of the sent packet. This mitigation is useful if the connection has an ephemeral forward-secure key that is generated -and used for every new connection. If a packet sent is encrypted with a +and used for every new connection. If a packet sent is protected with a forward-secure key, then any acknowledgments that are received for them MUST -also be forward-secure encrypted. Since the attacker will not have the forward -secure key, the attacker will not be able to generate forward-secure encrypted +also be forward-secure protected. Since the attacker will not have the forward +secure key, the attacker will not be able to generate forward-secure protected packets with ACK frames.