Merge pull request #1514 from quicwg/allow-retry-0rtt

Permit 0-RTT after Retry and VN

draft-ietf-quic-recovery.md

@@ -346,14 +346,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 timer 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.
+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}
 

draft-ietf-quic-tls.md

@@ -583,14 +583,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}})

draft-ietf-quic-transport.md

@@ -607,6 +607,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 a new value of at least 8
 octets in length.  This allows clients to distinguish between Retry packets when
@@ -746,7 +751,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
@@ -785,6 +790,32 @@ 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 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.  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
+Retry or Version Negotiation packet unless the client also regenerates the
+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
+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
@@ -1326,6 +1357,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
+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
 {{version-validation}}).