From 7bcd58fe079f032494fc2e9cb5ef335ac4bf092a Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 10 Oct 2017 12:37:31 +1100 Subject: [PATCH 1/5] Rename and consolidate packet types The two cleartext types are no longer needed to distinguish between client and server. Server packets are protected with a different key to that used for client packets, so a server will be unable to process a packet from another server as though it were a client packet (not that this was possible anyway given that we have a different type for the initial packet). Consequently, I have renamed packets to use shorter names and to better fit their roles: * Client Initial -> Initial * Server Stateless Retry -> Retry (also avoids confusion with Stateless Reset) * Server Cleartext -> Handshake * Client Cleartext -> Handshake I've rephrased the text in the TLS spec to match. The only functional change here is to consolidate Server and Client Cleartext into a single codepoint. I did renumber the 0-RTT and 1-RTT protected packets as a result. Closes #846. --- draft-ietf-quic-tls.md | 96 +++++++++--------- draft-ietf-quic-transport.md | 183 ++++++++++++++++------------------- 2 files changed, 131 insertions(+), 148 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 888685ed5e..694e599e20 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -318,7 +318,7 @@ ensures that TLS handshake messages are delivered in the correct order. Replayable QUIC Frames --------> - QUIC STREAM Frame <0>: @C + QUIC STREAM Frame <0>: @H ServerHello {TLS Handshake Messages} <-------- @@ -326,7 +326,7 @@ ensures that TLS handshake messages are delivered in the correct order. QUIC Frames @1 <-------- -@C QUIC STREAM Frame(s) <0>: +@H QUIC STREAM Frame(s) <0>: (EndOfEarlyData) {Finished} --------> @@ -339,8 +339,8 @@ In {{quic-tls-handshake}}, symbols mean: * "<" and ">" enclose stream numbers. -* "@" indicates the keys that are used for protecting the QUIC packet (C = - cleartext, with integrity only; 0 = 0-RTT keys; 1 = 1-RTT keys). +* "@" indicates the keys that are used for protecting the QUIC packet (H = + handshake, 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. @@ -349,14 +349,16 @@ In {{quic-tls-handshake}}, symbols mean: 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 -cleartext packets (@C) to 1-RTT protection (@1), which happens after it sends +handshake packets (@H) 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. +Note: two different types of packet are used during the handshake by both client +and server. The Initial packet carries a TLS ClientHello message; the remainder +of the TLS handshake is carried in Handshake packets. The Retry packet carries +a TLS HelloRetryRequest, if it is needed, and Handshake packets carry the +remainder of the server handshake. -The server sends TLS handshake messages without protection (@C). The server +The server sends TLS handshake messages without protection (@H). The server transitions from no protection (@C) to full 1-RTT protection (@1) after it sends the last of its handshake messages. @@ -365,13 +367,13 @@ protection. These keys are not exported from the TLS connection for use in QUIC. QUIC packets from the server are sent in the clear until the final transition to 1-RTT keys. -The client transitions from cleartext (@C) to 0-RTT keys (@0) when sending 0-RTT +The client transitions from handshake (@H) to 0-RTT keys (@0) when sending 0-RTT data, and subsequently to to 1-RTT keys (@1) after its second flight of TLS handshake messages. This creates the potential for unprotected packets to be received by a server in close proximity to packets that are protected with 1-RTT keys. -More information on key transitions is included in {{cleartext-hs}}. +More information on key transitions is included in {{hs-protection}}. ## Interface to TLS @@ -482,8 +484,8 @@ client and server, this occurs after sending the TLS Finished message. This ordering means that there could be frames that carry TLS handshake messages ready to send at the same time that application data is available. An implementation MUST ensure that TLS handshake messages are always sent in -cleartext packets. Separate packets are required for data that needs protection -from 1-RTT keys. +packets protected with handshake keys (see {{handshake-secrets}}). Separate +packets are required for data that needs protection from 1-RTT keys. If 0-RTT is possible, it is ready after the client sends a TLS ClientHello message or the server receives that message. After providing a QUIC client with @@ -618,11 +620,11 @@ As TLS reports the availability of keying material, the packet protection keys and initialization vectors (IVs) are updated (see {{key-expansion}}). The selection of AEAD function is also updated to match the AEAD negotiated by TLS. -For packets other than any unprotected handshake packets (see {{cleartext-hs}}), -once a change of keys has been made, packets with higher packet numbers MUST be -sent with the new keying material. The KEY_PHASE bit on these packets is -inverted each time new keys are installed to signal the use of the new keys to -the recipient (see {{key-phases}} for details). +For packets other than any handshake packets (see {{hs-protection}}), once a +change of keys has been made, packets with higher packet numbers MUST be sent +with the new keying material. The KEY_PHASE bit on these packets is inverted +each time new keys are installed to signal the use of the new keys to the +recipient (see {{key-phases}} for details). An endpoint retransmits stream data in a new packet. New packets have new packet numbers and use the latest packet protection keys. This simplifies key @@ -640,36 +642,35 @@ QUIC uses HKDF with the same hash function negotiated by TLS for key derivation. For example, if TLS is using the TLS_AES_128_GCM_SHA256, the SHA-256 hash function is used. +### Handshake Secrets {#handshake-secrets} -### Cleartext Packet Secrets {#cleartext-secrets} - -Cleartext packets are protected with secrets derived from the client's -connection ID. Specifically: +Packets that carry the TLS handshake (Initial, Retry, and Handshake) are +protected with secrets derived from the client's connection ID. Specifically: ~~~ quic_version_1_salt = afc824ec5fc77eca1e9d36f37fb2d46518c36639 - cleartext_secret = HKDF-Extract(quic_version_1_salt, + handshake_secret = HKDF-Extract(quic_version_1_salt, client_connection_id) - client_cleartext_secret = - HKDF-Expand-Label(cleartext_secret, - "QUIC client cleartext Secret", + client_handshake_secret = + HKDF-Expand-Label(handshake_secret, + "QUIC client handshake secret", "", Hash.length) - server_cleartext_secret = - HKDF-Expand-Label(cleartext_secret, - "QUIC server cleartext Secret", + server_handshake_secret = + HKDF-Expand-Label(handshake_secret, + "QUIC server handshake secret", "", Hash.length) ~~~ -The HKDF for the cleartext packet protection keys uses the SHA-256 hash function -{{FIPS180}}. +The HKDF for the handshake secrets and keys derived from them uses the SHA-256 +hash function {{FIPS180}}. The salt value is a 16 octet 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 cleartext packets from future versions. +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 handshake packets from future versions. ### 0-RTT Secret {#zero-rtt-secrets} @@ -798,9 +799,9 @@ connection. For example, if TLS is using the TLS_AES_128_GCM_SHA256, the AEAD_AES_128_GCM function is used. All QUIC packets other than Version Negotiation and Stateless Reset packets are -protected with an AEAD algorithm {{!RFC5116}}. Cleartext packets are protected +protected with an AEAD algorithm {{!RFC5116}}. Handshake packets are protected with AEAD_AES_128_GCM and a key derived from the client's connection ID (see -{{cleartext-secrets}}). This provides protection against off-path attackers and +{{handshake-secrets}}). This provides protection against off-path attackers and robustness against QUIC version unaware middleboxes, but not against on-path attackers. @@ -907,12 +908,12 @@ Transitions between keys during the handshake are complicated by the need to ensure that TLS handshake messages are sent with the correct packet protection. -## Packet Protection for the TLS Handshake {#cleartext-hs} +## Packet Protection for the TLS Handshake {#hs-protection} -The initial exchange of packets are sent using a cleartext packet type -and AEAD-protected using the cleartext key generated as described in -{{cleartext-secrets}}. All TLS handshake messages up to the TLS -Finished message sent by either endpoint use cleartext packets. +The initial exchange of packets that carry the TLS handshake are AEAD-protected +using the connection setup key generated as described in {{handshake-secrets}}. +All TLS handshake messages up to the TLS Finished message sent by either +endpoint use packets protected with handshake keys. Any TLS handshake messages that are sent after completing the TLS handshake do not need special packet protection rules. Packets containing these messages use @@ -921,7 +922,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 cleartext packets. +client in packets protected with handshake keys. ### Initial Key Transitions {#first-keys} @@ -933,8 +934,8 @@ 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}}). 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. +contains the TLS EndOfEarlyData and Finished messages are sent in packets +protected with handshake keys. 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 @@ -963,8 +964,9 @@ 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 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. +of these handshake messages MUST be sent in packets protected with handshake +keys. An endpoint MUST generate ACK frames for these messages and send them in +packets protected with handshake keys. A HelloRetryRequest handshake message might be used to reject an initial ClientHello. A HelloRetryRequest handshake message is sent in a Server diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 8bef871f0e..42079e5d78 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -414,13 +414,12 @@ The following packet types are defined: | Type | Name | Section | |:-----|:------------------------------|:----------------------------| | 0x01 | Version Negotiation | {{packet-version}} | -| 0x02 | Client Initial | {{packet-client-initial}} | -| 0x03 | Server Stateless Retry | {{packet-server-stateless}} | -| 0x04 | Server Cleartext | {{packet-server-cleartext}} | -| 0x05 | Client Cleartext | {{packet-client-cleartext}} | -| 0x06 | 0-RTT Protected | {{packet-protected}} | -| 0x07 | 1-RTT Protected (key phase 0) | {{packet-protected}} | -| 0x08 | 1-RTT Protected (key phase 1) | {{packet-protected}} | +| 0x02 | Initial | {{packet-initial}} | +| 0x03 | Retry | {{packet-retry}} | +| 0x04 | Handshake | {{packet-handshake}} | +| 0x05 | 0-RTT Protected | {{packet-protected}} | +| 0x06 | 1-RTT Protected (key phase 0) | {{packet-protected}} | +| 0x07 | 1-RTT Protected (key phase 1) | {{packet-protected}} | {: #long-packet-types title="Long Header Packet Types"} The header form, packet type, connection ID, packet number and version fields of @@ -522,8 +521,8 @@ server received the packet and that the Version Negotiation packet was not carried in a packet with a spoofed source address. A Version Negotiation packet is never explicitly acknowledged in an ACK frame by -a client. Receiving another Client Initial packet implicitly acknowledges a -Version Negotiation packet. +a client. Receiving another Initial packet implicitly acknowledges a Version +Negotiation packet. The payload of the Version Negotiation packet is a list of 32-bit versions which the server supports, as shown below. @@ -547,70 +546,70 @@ See {{version-negotiation}} for a description of the version negotiation process. -## Cleartext Packets {#cleartext-packet} +## Cryptographic Handshake Packets {#handshake-packets} -Cleartext packets are sent during the handshake prior to key negotiation. +Once version negotiation is complete, the cryptographic handshake is used to +agree on cryptographic keys. The cryptographic handshake is carried in Initial +({{packet-initial}}), Retry ({{packet-retry}}) and Handshake +({{packet-handshake}}) packets. -All cleartext packets contain the current QUIC version in the version field. +All these packets use the long header and contain the current QUIC version in +the version field. -In order to prevent tampering by version-unaware middleboxes, Cleartext -packets are protected with a connection and version specific key, as -described in {{QUIC-TLS}}. This protection does not provide confidentiality -or integrity against on-path attackers, but provides some level of -protection against off-path attackers. +In order to prevent tampering by version-unaware middleboxes, handshake packets +are protected with a connection and version specific key, as described in +{{QUIC-TLS}}. This protection does not provide confidentiality or integrity +against on-path attackers, but provides some level of protection against +off-path attackers. -### Client Initial Packet {#packet-client-initial} +### Initial Packet {#packet-initial} -The Client Initial packet uses long headers with a type value of 0x02. -It carries the first cryptographic handshake message sent by the client. +The Initial packet uses long headers with a type value of 0x02. It carries the +first cryptographic handshake message sent by the client. The client populates the connection ID field with randomly selected values, unless it has received a packet from the server. If the client has received a packet from the server, the connection ID field uses the value provided by the server. -The packet number used for Client Initial packets is initialized with a random -value each time the new contents are created for the packet. Retransmissions of -the packet contents increment the packet number by one, see -({{packet-numbers}}). +The packet number used for Initial packets is initialized with a random value +each time the new contents are created for the packet. Retransmissions of the +packet contents increment the packet number by one, see ({{packet-numbers}}). -The payload of a Client Initial packet consists of a STREAM frame (or frames) +The payload of a Initial packet consists of a STREAM frame (or frames) for stream 0 containing a cryptographic handshake message, with enough PADDING frames that the packet is at least 1200 octets (see {{packetization}}). The stream in this packet always starts at an offset of 0 (see {{stateless-retry}}) and the complete cryptographic handshake message MUST fit in a single packet (see {{handshake}}). -The client uses the Client Initial Packet type for any packet that contains an -initial cryptographic handshake message. This includes all cases where a new -packet containing the initial cryptographic message needs to be created, this -includes the packets sent after receiving a Version Negotiation -({{packet-version}}) or Server Stateless Retry packet -({{packet-server-stateless}}). +The client uses the Initial Packet type for any packet that contains an initial +cryptographic handshake message. This includes all cases where a new packet +containing the initial cryptographic message needs to be created, this includes +the packets sent after receiving a Version Negotiation ({{packet-version}}) or +Retry packet ({{packet-retry}}). -### Server Stateless Retry Packet {#packet-server-stateless} +### Retry Packet {#packet-retry} -A Server Stateless Retry packet uses long headers with a type value of 0x03. -It carries cryptographic handshake messages and acknowledgments. It is used -by a server that wishes to perform a stateless retry (see -{{stateless-retry}}). +A Retry packet uses long headers with a type value of 0x03. It carries +cryptographic handshake messages and acknowledgments. It is used by a server +that wishes to perform a stateless retry (see {{stateless-retry}}). The packet number and connection ID fields echo the corresponding fields from the triggering client packet. This allows a client to verify that the server received its packet. -A Server Stateless Retry packet is never explicitly acknowledged in an ACK frame -by a client. Receiving another Client Initial packet implicitly acknowledges a -Server Stateless Retry packet. +A Retry packet is never explicitly acknowledged in an ACK frame +by a client. Receiving another Initial packet implicitly acknowledges a Retry +packet. -After receiving a Server Stateless Retry packet, the client uses a new Client -Initial packet containing the next cryptographic handshake message. The client -retains the state of its cryptographic handshake, but discards all transport -state. The new Client Initial packet includes a newly randomized packet number, -STREAM frames on stream 0 that start again at an offset of 0, and the original -connection ID. +After receiving a Retry packet, the client uses a new Initial packet containing +the next cryptographic handshake message. The client retains the state of its +cryptographic handshake, but discards all transport state. The new Initial +packet includes a newly randomized packet number, STREAM frames on stream 0 that +start again at an offset of 0, and the original connection ID. Continuing the cryptographic handshake is necessary to ensure that an attacker cannot force a downgrade of any cryptographic parameters. In addition to @@ -619,41 +618,26 @@ any version negotiation that occurred (see {{version-negotiation}}). The client MAY also retain any observed RTT or congestion state that it has accumulated for the flow, but other transport state MUST be discarded. -The payload of the Server Stateless Retry packet contains a single STREAM frame +The payload of the Retry packet contains a single STREAM frame on stream 0 with offset 0 containing the server's cryptographic stateless retry material. It MUST NOT contain any other frames. The next STREAM frame sent by the server will also start at stream offset 0. -### Server Cleartext Packet {#packet-server-cleartext} +### Handshake Packet {#packet-handshake} -A Server Cleartext packet uses long headers with a type value of 0x04. It is +A Handshake packet uses long headers with a type value of 0x04. It is used to carry acknowledgments and cryptographic handshake messages from the -server. +server and client. -The connection ID field in a Server Cleartext packet contains a connection ID +The connection ID field in a Handshake packet contains a connection ID that is chosen by the server (see {{connection-id}}). -The first Server Cleartext packet contains a randomized packet number. This -value is increased for each subsequent packet sent by the server as described in -{{packet-numbers}}. - -The payload of this packet contains STREAM frames and could contain PADDING and -ACK frames. - - -### Client Cleartext Packet {#packet-client-cleartext} - -A Client Cleartext packet uses long headers with a type value of 0x05, and is -sent when the client has received a Server Cleartext packet from the server. - -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 Protected or Client Cleartext packet that was sent. -The packet number is incremented for each subsequent packet, see -{{packet-numbers}}. +The first Handshake packet sent by a server contains a randomized packet number. +This value is increased for each subsequent packet sent by the server as +described in {{packet-numbers}}. The client increments the packet number from +its previous packet by one for each Handshake packet that it sends (which might +be an Initial, 0-RTT Protected, or Handshake packet). The payload of this packet contains STREAM frames and could contain PADDING and ACK frames. @@ -666,7 +650,7 @@ that are protected with 1-RTT keys MAY be sent with long headers. The different packet types explicitly indicate the encryption level and therefore the keys that are used to remove packet protection. -Packets protected with 0-RTT keys use a type value of 0x06. The connection ID +Packets protected with 0-RTT keys use a type value of 0x05. The connection ID field for a 0-RTT packet is selected by the client. The client can send 0-RTT packets after having received a packet from the server @@ -674,8 +658,8 @@ if that packet does not complete the handshake. Even if the client receives a different connection ID from the server, it MUST NOT update the connection ID it uses for 0-RTT packets. This enables consistent routing for all 0-RTT packets. -Packets protected with 1-RTT keys that use long headers use a type value of 0x07 -for key phase 0 and 0x08 for key phase 1; see {{QUIC-TLS}} for more details on +Packets protected with 1-RTT keys that use long headers use a type value of 0x06 +for key phase 0 and 0x07 for key phase 1; see {{QUIC-TLS}} for more details on the use of key phases. The connection ID field for these packet types MUST contain the value selected by the server, see {{connection-id}}. @@ -697,14 +681,14 @@ using the CONNECTION_ID flag. When present, the Connection ID is in the same location in all packet headers, making it straightforward for middleboxes, such as load balancers, to locate and use it. -The client MUST choose a random connection ID and use it in Client Initial -packets ({{packet-client-initial}}) and 0-RTT packets ({{packet-protected}}). -If the client has received any packet from the server, it uses the connection ID -it received from the server for all packets other than 0-RTT packets. +The client MUST choose a random connection ID and use it in Initial packets +({{packet-initial}}) and 0-RTT packets ({{packet-protected}}). If the client +has received any packet from the server, it uses the connection ID it received +from the server for all packets other than 0-RTT packets. -When the server receives a Client Initial packet and decides to proceed with the +When the server receives a Initial packet and decides to proceed with the handshake, it chooses a new value for the connection ID and sends that in a -Server Cleartext packet. The server MAY choose to use the value that the client +Handshake packet. The server MAY choose to use the value that the client initially selects. Once the client receives the connection ID that the server has chosen, it uses @@ -754,9 +738,8 @@ sending a packet with a number of 0x6b4264 requires a 16-bit or larger packet number encoding; whereas a 32-bit packet number is needed to send a packet with a number of 0x6bc107. -Version Negotiation ({{packet-version}}) and Server Stateless Retry -({{packet-server-stateless}}) packets have special rules for populating the -packet number field. +Version Negotiation ({{packet-version}}) and Retry ({{packet-retry}}) packets +have special rules for populating the packet number field. ### Initial Packet Number {#initial-packet-number} @@ -770,11 +753,11 @@ The first set of packets sent by an endpoint MUST include the low 32-bits of the packet number. Once any packet has been acknowledged, subsequent packets can use a shorter packet number encoding. -A client that receives a Version Negotiation ({{packet-version}}) or Server -Stateless Retry packet ({{packet-server-stateless}}) MUST generate a new initial -packet number. This ensures that the first transmission attempt for a Client -Initial packet ({{packet-client-initial}}) always contains a randomized packet -number, but packets that contain retransmissions increment the packet number. +A client that receives a Version Negotiation ({{packet-version}}) or Retry +packet ({{packet-retry}}) MUST generate a new initial packet number. This +ensures that the first transmission attempt for a Initial packet +({{packet-initial}}) always contains a randomized packet number, but packets +that contain retransmissions increment the packet number. A client MUST NOT generate a new initial packet number if it discards the server packet. This might happen if the information the client retransmits its Client @@ -805,8 +788,8 @@ an unsupported version. # Frames and Frame Types {#frames} -The payload of cleartext packets and the plaintext after decryption of protected -payloads consists of a sequence of frames, as shown in {{packet-frames}}. +The payload of Initial, Handshake and all protected packets consists of a +sequence of frames, as shown in {{packet-frames}}. ~~~ 0 1 2 3 @@ -1244,17 +1227,16 @@ without committing any state. This allows a server to perform address validation ({{address-validation}}, or to defer connection establishment costs. A server that generates a response to an initial packet without retaining -connection state MUST use the Server Stateless Retry packet -({{packet-server-stateless}}). This packet causes a client to reset its -transport state and to continue the connection attempt with new connection state -while maintaining the state of the cryptographic handshake. +connection state MUST use the Retry packet ({{packet-retry}}). This packet +causes a client to reset its transport state and to continue the connection +attempt with new connection state while maintaining the state of the +cryptographic handshake. -A server MUST NOT send multiple Server Stateless Retry packets in response to a -client handshake packet. Thus, any cryptographic handshake message that is sent -MUST fit within a single packet. +A server MUST NOT send multiple Retry packets in response to a client handshake +packet. Thus, any cryptographic handshake message that is sent MUST fit within +a single packet. -In TLS, the Server Stateless Retry packet type is used to carry the -HelloRetryRequest message. +In TLS, the Retry packet type is used to carry the HelloRetryRequest message. ## Proof of Source Address Ownership {#address-validation} @@ -2050,9 +2032,8 @@ Unlike TCP SACKs, QUIC ACK blocks are irrevocable. Once a packet has been acknowledged, even if it does not appear in a future ACK frame, it remains acknowledged. -A client MUST NOT acknowledge Version Negotiation or Server Stateless Retry -packets. These packet types contain packet numbers selected by the client, not -the server. +A client MUST NOT acknowledge Version Negotiation or Retry packets. These +packet types contain packet numbers selected by the client, not the server. A sender MAY intentionally skip packet numbers to introduce entropy into the connection, to avoid opportunistic acknowledgement attacks. The sender SHOULD From 2d80e8f6511b57cecabf1edc8819b6529fd9d4aa Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 10 Oct 2017 12:44:54 +1100 Subject: [PATCH 2/5] Handshake, not connection setup --- draft-ietf-quic-tls.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 694e599e20..26ef82a094 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -911,7 +911,7 @@ ensure that TLS handshake messages are sent with the correct packet protection. ## Packet Protection for the TLS Handshake {#hs-protection} The initial exchange of packets that carry the TLS handshake are AEAD-protected -using the connection setup key generated as described in {{handshake-secrets}}. +using the handshake secrets generated as described in {{handshake-secrets}}. All TLS handshake messages up to the TLS Finished message sent by either endpoint use packets protected with handshake keys. From 070a4b016f56bb4d0cf0b15a8b10baf3afb2a27b Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 11 Oct 2017 13:50:08 +1100 Subject: [PATCH 3/5] Nits --- draft-ietf-quic-transport.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 42079e5d78..68fdd04606 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -557,7 +557,7 @@ All these packets use the long header and contain the current QUIC version in the version field. In order to prevent tampering by version-unaware middleboxes, handshake packets -are protected with a connection and version specific key, as described in +are protected with a connection- and version-specific key, as described in {{QUIC-TLS}}. This protection does not provide confidentiality or integrity against on-path attackers, but provides some level of protection against off-path attackers. @@ -584,7 +584,7 @@ stream in this packet always starts at an offset of 0 (see {{stateless-retry}}) and the complete cryptographic handshake message MUST fit in a single packet (see {{handshake}}). -The client uses the Initial Packet type for any packet that contains an initial +The client uses the Initial packet type for any packet that contains an initial cryptographic handshake message. This includes all cases where a new packet containing the initial cryptographic message needs to be created, this includes the packets sent after receiving a Version Negotiation ({{packet-version}}) or @@ -788,8 +788,9 @@ an unsupported version. # Frames and Frame Types {#frames} -The payload of Initial, Handshake and all protected packets consists of a -sequence of frames, as shown in {{packet-frames}}. +The payload of all packets, after removing packet protection, consists of a +sequence of frames, as shown in {{packet-frames}}. Version Negotiation and +Stateless Reset do not contain frames. ~~~ 0 1 2 3 From 670ede097e8360532c1f1edb3eba7b39870b3e55 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 11 Oct 2017 13:59:29 +1100 Subject: [PATCH 4/5] Rewrap --- draft-ietf-quic-tls.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 26ef82a094..e316253574 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -667,10 +667,10 @@ The HKDF for the handshake secrets and keys derived from them uses the SHA-256 hash function {{FIPS180}}. The salt value is a 16 octet 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 handshake packets from future versions. +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 handshake packets from future versions. ### 0-RTT Secret {#zero-rtt-secrets} From 6898686e483267d139d3e44d949a2a86e89249e3 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 20 Oct 2017 10:05:03 +1100 Subject: [PATCH 5/5] Reflow, fix links, Closes #822 --- draft-ietf-quic-transport.md | 46 +++++++++++++++++------------------- 1 file changed, 22 insertions(+), 24 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 920391e11a..c182b42d25 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -570,9 +570,9 @@ unless it has received a packet from the server. If the client has received a packet from the server, the connection ID field uses the value provided by the server. -The first Initial packet that is sent by a client contains a random -31-bit value. All subsequent packets contain a packet number that is -incremented by one, see ({{packet-numbers}}). +The first Initial packet that is sent by a client contains a random 31-bit +value. All subsequent packets contain a packet number that is incremented by +one, see ({{packet-numbers}}). The payload of a Initial packet consists of a STREAM frame (or frames) for stream 0 containing a cryptographic handshake message, with enough PADDING @@ -602,10 +602,10 @@ A Retry packet is never explicitly acknowledged in an ACK frame by a client. Receiving another Initial packet implicitly acknowledges a Retry packet. -After receiving a Retry packet, the client uses a new +After receiving a Retry packet, the client uses a new Initial packet containing the next cryptographic handshake message. The client retains the state of its cryptographic handshake, but discards all transport -state. The Initial packet that is generated in response to a Retry packet +state. The Initial packet that is generated in response to a Retry packet includes STREAM frames on stream 0 that start again at an offset of 0. Continuing the cryptographic handshake is necessary to ensure that an attacker @@ -651,10 +651,10 @@ Packets protected with 0-RTT keys use a type value of 0x05. The connection ID field for a 0-RTT packet is selected by the client. The client can send 0-RTT packets after receiving a Handshake packet -({{packet-server-cleartext}}), if that packet does not complete the handshake. -Even if the client receives a different connection ID in the Handshake -packet, it MUST continue to use the connection ID selected by the client for -0-RTT packets, see {{connection-id}}. +({{packet-handshake}}), if that packet does not complete the handshake. Even if +the client receives a different connection ID in the Handshake packet, it MUST +continue to use the connection ID selected by the client for 0-RTT packets, see +{{connection-id}}. The version field for protected packets is the current QUIC version. @@ -674,22 +674,20 @@ using the CONNECTION_ID flag. When present, the Connection ID is in the same location in all packet headers, making it straightforward for middleboxes, such as load balancers, to locate and use it. -The client MUST choose a random connection ID and use it in Initial -packets ({{packet-initial}}) and 0-RTT packets ({{packet-protected}}). +The client MUST choose a random connection ID and use it in Initial packets +({{packet-initial}}) and 0-RTT packets ({{packet-protected}}). When the server receives a Initial packet and decides to proceed with the handshake, it chooses a new value for the connection ID and sends that in a -Handshake packet ({{packet-handshake}}). The server MAY choose to -use the value that the client initially selects. +Handshake packet ({{packet-handshake}}). The server MAY choose to use the value +that the client initially selects. Once the client receives the connection ID that the server has chosen, it MUST -use it for all subsequent Handshake ({{packet-handshake}}) and -1-RTT ({{packet-protected}}) packets but not for 0-RTT packets -({{packet-protected}}). +use it for all subsequent Handshake ({{packet-handshake}}) and 1-RTT +({{packet-protected}}) packets but not for 0-RTT packets ({{packet-protected}}). -Server's Version Negotiation ({{packet-version}}) and Retry -({{packet-retry}}) packets MUST use connection ID selected by the -client. +Server's Version Negotiation ({{packet-version}}) and Retry ({{packet-retry}}) +packets MUST use connection ID selected by the client. ## Packet Numbers {#packet-numbers} @@ -905,11 +903,11 @@ QUIC's connection establishment begins with version negotiation, since all communication between the endpoints, including packet and frame formats, relies on the two endpoints agreeing on a version. -A QUIC connection begins with a client sending a Client Initial packet -({{packet-client-initial}}). The details of the handshake mechanisms are -described in {{handshake}}, but all of the initial packets sent from the client -to the server MUST use the long header format - which includes the version of -the protocol being used - and they MUST be padded to at least 1200 octets. +A QUIC connection begins with a client sending an Initial packet +({{packet-initial}}). The details of the handshake mechanisms are described in +{{handshake}}, but any Initial packet sent from the client to the server MUST +use the long header format - which includes the version of the protocol being +used - and they MUST be padded to at least 1200 octets. The server receives this packet and determines whether it potentially creates a new connection (see {{packet-handling}}). If the packet might generate a new