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

@@ -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}
 

draft-ietf-quic-transport.md

@@ -601,6 +601,11 @@ the packet.  This prevents an off-path attacker from injecting a Retry packet.
 The client responds to a Retry packet with 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
@@ -727,16 +732,17 @@ 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 client SHOULD NOT reuse a token.  Reusing a token on different network paths
-would allow activity to be linked between paths (see {{migration-linkability}}).
-A client MUST NOT reuse a token if it believes that its point of network
-attachment has changed; that is, if there is a change in its local IP address or
-network interface.  A client needs to start the connection process over if it
-migrates prior to completing the handshake.
+A client SHOULD NOT reuse a token; reused tokens enable activity on connections
+to be correlated.  A client MUST NOT reuse a token if it believes that its point
+of network attachment has changed; that is, if there is a change in its local IP
+address or network interface.  Reusing a token on different network paths would
+allow activity to be linked between paths (see {{migration-linkability}}).  A
+client needs to start the connection process over if it migrates prior to
+completing the handshake.
 
 If the client received a Retry packet from the server and sends an Initial
 packet in response, then it sets the Destination Connection ID to the value from
@@ -770,6 +776,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
@@ -1311,6 +1339,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}}).