From fe488635a6385c7dd58ee730b5137bd900085e53 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 3 Jul 2018 15:52:43 +1000 Subject: [PATCH 1/9] Permit 0-RTT after Retry and VN After the discussion on #1507, I've been convinced that there is no real value in preventing a client from attempting 0-RTT after a Retry. And, it would seem like Version Negotiation has essentially the same properties, so excluding it would be inconsistent. This allows this, explores the consequences for packet numbers (don't reset them!), and updates the recovery text to include Version Negotiation. Closes #1507. --- draft-ietf-quic-recovery.md | 12 ++++++------ draft-ietf-quic-transport.md | 37 +++++++++++++++++++++++++++++++++--- 2 files changed, 40 insertions(+), 9 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 42f71a6dbb..5e50afacb2 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -306,14 +306,14 @@ the CRYPTO frames were sent at 1RTT encryption. When an acknowledgement is received for a handshake packet, the new RTT is computed and the alarm SHOULD be set for twice the newly computed smoothed RTT. -#### Retry +#### Retry and Version Negotiation -A Retry packet causes the content of the client's Initial packet to be -immediately retransmitted along with the token present in the Retry. +A Retry or Version Negotiation packet causes a client to send another Initial +packet, effectively restarting the connection process. -The Retry indicates that the Initial was received but not processed. It MUST -NOT be treated as an acknowledgment for the Initial, but it MAY be used for an -RTT measurement. +Either packet indicates that the Initial was received but not processed. Either +packet cannot be treated as an acknowledgment for the Initial, but they MAY be +used to improve the RTT estimate. ### Tail Loss Probe {#tlp} diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 12878a27bf..80ce2f6073 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -603,6 +603,11 @@ the packet. This prevents an off-path attacker from injecting a Retry packet. The client responds to a Retry packet with an Initial packet that includes the provided Retry Token to continue connection establishment. +A client MAY attempt 0-RTT after receiving a Retry packet by sending 0-RTT +packets to the connection ID provided by the server. A client that sends +additional 0-RTT packets MUST NOT reset the packet number to 0 after a Retry +packet, see {{retry-0rtt-pn}}. + A server that might send another Retry packet in response to a subsequent Initial packet MUST set the Source Connection ID to new value of at least 8 octets in length. This allows clients to distinguish between Retry packets when @@ -729,9 +734,9 @@ Connection ID. ### Tokens -If the client has a token received in a NEW_TOKEN frame on a previous connection -to what it believes to be the same server, it can include that value in the -Token field of its Initial packet. +If the client has an token received in a NEW_TOKEN frame on a previous +connection to what it believes to be the same server, it can include that value +in the Token field of its Initial packet. A token allows a server to correlate activity between connections. Specifically, the connection where the token was issued, and any connection @@ -778,6 +783,28 @@ are in a different packet number space to other packets (see {{packet-numbers}}). +### 0-RTT Packet Numbers {#retry-0rtt-pn} + +Packet numbers for 0-RTT protected packets use the same space as 0-RTT protected +packets. + +After a client receives a Retry or Version Negotiation packet, it MAY attempt to +send data in 0-RTT packets after it sends a new Initial packet. However, a +client MUST NOT reset the packet number it uses for 0-RTT packets. The keys +used to protect 0-RTT keys are not guaranteed to change as a result of +responding to a Retry or Version Negotiation packet. + +Receiving a Retry or Version Negotiation packet, especially a Retry that changes +the connection ID used for subsequent packets, indicates a strong possibility +that 0-RTT packets could be lost. A client only receives acknowledgments for +its 0-RTT packets once the handshake is complete. Consequently, a server might +expect 0-RTT packets to start with a packet number of 0. Therefore, in +determining the length of the packet number encoding for 0-RTT packets, a client +MUST assume that all packets up to the current packet number are in flight, +starting from a packet number of 0. Thus, 0-RTT packets could need to use a +longer packet number encoding. + + ### Minimum Packet Size The payload of a UDP datagram carrying the Initial packet MUST be expanded to at @@ -1319,6 +1346,10 @@ Version Negotiation packet. A client MUST ignore a Version Negotiation packet that lists the client's chosen version. +A client MAY attempt 0-RTT after receiving a Version Negotiation packet. A +client that sends additional 0-RTT packets MUST NOT reset the packet number to 0 +after a Retry packet, see {{retry-0rtt-pn}}. + Version negotiation packets have no cryptographic protection. The result of the negotiation MUST be revalidated as part of the cryptographic handshake (see {{version-validation}}). From 88fc5603531cec98cab109addf990b848dbc2d4d Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 3 Jul 2018 16:18:00 +1000 Subject: [PATCH 2/9] 0-RTT, 1-RTT, same thing --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 80ce2f6073..f4dae1c706 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -785,7 +785,7 @@ are in a different packet number space to other packets (see ### 0-RTT Packet Numbers {#retry-0rtt-pn} -Packet numbers for 0-RTT protected packets use the same space as 0-RTT protected +Packet numbers for 0-RTT protected packets use the same space as 1-RTT protected packets. After a client receives a Retry or Version Negotiation packet, it MAY attempt to From 620c5830091b9f5b26ed9bfdf11ddf7bfe2cba42 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 4 Jul 2018 09:03:02 +1000 Subject: [PATCH 3/9] Clarify key changes --- draft-ietf-quic-transport.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index f4dae1c706..8634a3ad9b 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -791,8 +791,9 @@ packets. After a client receives a Retry or Version Negotiation packet, it MAY attempt to send data in 0-RTT packets after it sends a new Initial packet. However, a client MUST NOT reset the packet number it uses for 0-RTT packets. The keys -used to protect 0-RTT keys are not guaranteed to change as a result of -responding to a Retry or Version Negotiation packet. +used to protect 0-RTT packets will not change as a result of responding to a +Retry or Version Negotiation packet unless the client also regenerates the +cryptographic handshake messages. Receiving a Retry or Version Negotiation packet, especially a Retry that changes the connection ID used for subsequent packets, indicates a strong possibility From b6c48beb79867e0f961252b394612e9ebe8ce615 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 4 Jul 2018 16:39:13 +1000 Subject: [PATCH 4/9] Redo fixes I already committed somewhere else, I swear --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 8634a3ad9b..0801dfe3b6 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -734,7 +734,7 @@ Connection ID. ### Tokens -If the client has an token received in a NEW_TOKEN frame on a previous +If the client has a token received in a NEW_TOKEN frame on a previous connection to what it believes to be the same server, it can include that value in the Token field of its Initial packet. From e2b9137a7ad9f4c22e39fa762f776242c33916c1 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 6 Jul 2018 10:21:28 +1000 Subject: [PATCH 5/9] Refinements --- draft-ietf-quic-recovery.md | 6 +++--- draft-ietf-quic-transport.md | 20 ++++++++++++-------- 2 files changed, 15 insertions(+), 11 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 5e50afacb2..df7f06fbc5 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -311,9 +311,9 @@ computed and the alarm SHOULD be set for twice the newly computed smoothed RTT. A Retry or Version Negotiation packet causes a client to send another Initial packet, effectively restarting the connection process. -Either packet indicates that the Initial was received but not processed. Either -packet cannot be treated as an acknowledgment for the Initial, but they MAY be -used to improve the RTT estimate. +Either packet indicates that the Initial was received but not processed. +Neither packet can be treated as an acknowledgment for the Initial, but they MAY +be used to improve the RTT estimate. ### Tail Loss Probe {#tlp} diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 0801dfe3b6..8c136488f0 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -734,9 +734,9 @@ Connection ID. ### Tokens -If the client has a token received in a NEW_TOKEN frame on a previous -connection to what it believes to be the same server, it can include that value -in the Token field of its Initial packet. +If the client has a token received in a NEW_TOKEN frame on a previous connection +to what it believes to be the same server, it can include that value in the +Token field of its Initial packet. A token allows a server to correlate activity between connections. Specifically, the connection where the token was issued, and any connection @@ -788,12 +788,16 @@ are in a different packet number space to other packets (see Packet numbers for 0-RTT protected packets use the same space as 1-RTT protected packets. -After a client receives a Retry or Version Negotiation packet, it MAY attempt to -send data in 0-RTT packets after it sends a new Initial packet. However, a -client MUST NOT reset the packet number it uses for 0-RTT packets. The keys +After a client receives a Retry or Version Negotiation packet, 0-RTT packets are +likely to be lost or discarded by the server, especially if the server changes +its connection ID with a Retry packet. A client MAY attempt to send data in +0-RTT packets after it sends a new Initial packet. + +A client MUST NOT reset the packet number it uses for 0-RTT packets. The keys used to protect 0-RTT packets will not change as a result of responding to a Retry or Version Negotiation packet unless the client also regenerates the -cryptographic handshake messages. +cryptographic handshake message. Sending packets with the same packet number in +that case would compromise the packet protection for all 0-RTT packets. Receiving a Retry or Version Negotiation packet, especially a Retry that changes the connection ID used for subsequent packets, indicates a strong possibility @@ -1349,7 +1353,7 @@ version. A client MAY attempt 0-RTT after receiving a Version Negotiation packet. A client that sends additional 0-RTT packets MUST NOT reset the packet number to 0 -after a Retry packet, see {{retry-0rtt-pn}}. +as a result, see {{retry-0rtt-pn}}. Version negotiation packets have no cryptographic protection. The result of the negotiation MUST be revalidated as part of the cryptographic handshake (see From 1011f5ee62e300237373931b4b2aa23fff19c9cd Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 9 Jul 2018 09:49:06 +1000 Subject: [PATCH 6/9] Have been --- draft-ietf-quic-transport.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 8c136488f0..52af0c14c4 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -789,9 +789,9 @@ Packet numbers for 0-RTT protected packets use the same space as 1-RTT protected packets. After a client receives a Retry or Version Negotiation packet, 0-RTT packets are -likely to be lost or discarded by the server, especially if the server changes -its connection ID with a Retry packet. A client MAY attempt to send data in -0-RTT packets after it sends a new Initial packet. +likely to have been lost or discarded by the server, especially if the server +changes its connection ID with a Retry packet. A client MAY attempt to resend +data in 0-RTT packets after it sends a new Initial packet. A client MUST NOT reset the packet number it uses for 0-RTT packets. The keys used to protect 0-RTT packets will not change as a result of responding to a From 2e13f0d6461c75a74c92d11fe07b83bcebfa0ed8 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 9 Jul 2018 14:28:05 +1000 Subject: [PATCH 7/9] Add text to the TLS spec too Closes #1168. --- draft-ietf-quic-tls.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index aef83a7990..b966698e21 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -572,14 +572,17 @@ as a connection error of type PROTOCOL_VIOLATION. ## Rejecting 0-RTT A server rejects 0-RTT by rejecting 0-RTT at the TLS layer. This also prevents -QUIC from sending 0-RTT data. A client that attempts 0-RTT MUST also consider -0-RTT to be rejected if it receives a Version Negotiation packet. +QUIC from sending 0-RTT data. A server will always reject 0-RTT if it sends a +TLS HelloRetryRequest. When 0-RTT is rejected, all connection characteristics that the client assumed might be incorrect. This includes the choice of application protocol, transport parameters, and any application configuration. The client therefore MUST reset the state of all streams, including application state bound to those streams. +A client MAY attempt to send 0-RTT again if it receives a Retry or Version +Negotiation packet. These packets do not signify rejection of 0-RTT. + ## HelloRetryRequest In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of {{!TLS13}}) From 25598fd7d7e6906030b99315b09a5e41aa2ce7af Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 9 Jul 2018 16:31:47 +1000 Subject: [PATCH 8/9] Extra 'on' --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 52af0c14c4..6ed2cf84c1 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -744,7 +744,7 @@ where it is used. Clients that want to break continuity of identity with a server MAY discard tokens provided using the NEW_TOKEN frame. Tokens obtained in Retry packets MUST NOT be discarded. -A client SHOULD NOT reuse a token. Reusing a token on allows connections to be +A client SHOULD NOT reuse a token. Reusing a token allows connections to be linked by entities on the network path (see {{migration-linkability}}). A client MUST NOT reuse a token if it believes that its point of network attachment has changed since the token was last used; that is, if there is a From 22deb75449751fd21fd75c48fdbbf16d94665daa Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 9 Jul 2018 19:54:01 +1000 Subject: [PATCH 9/9] Remove especially if text --- draft-ietf-quic-transport.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 6ed2cf84c1..9d67f1d062 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -789,9 +789,8 @@ Packet numbers for 0-RTT protected packets use the same space as 1-RTT protected packets. After a client receives a Retry or Version Negotiation packet, 0-RTT packets are -likely to have been lost or discarded by the server, especially if the server -changes its connection ID with a Retry packet. A client MAY attempt to resend -data in 0-RTT packets after it sends a new Initial packet. +likely to have been lost or discarded by the server. A client MAY attempt to +resend data in 0-RTT packets after it sends a new Initial packet. A client MUST NOT reset the packet number it uses for 0-RTT packets. The keys used to protect 0-RTT packets will not change as a result of responding to a