Explicitly permit starting over

Generating a new cryptographic handshake message is a fine response to
Retry or Version Negotiation.  It's sometimes necessary, but even when
it is not, it avoids having to worry about 0-RTT packet numbers.

Followup for #1498.

draft-ietf-quic-transport.md

@@ -806,7 +806,8 @@ 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.
+that case could compromise the packet protection for all 0-RTT packets because
+the combination of key and nonce could be used to protect different content.
 
 Receiving a Retry or Version Negotiation packet, especially a Retry that changes
 the connection ID used for subsequent packets, indicates a strong possibility
@@ -818,6 +819,12 @@ 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.
 
+A client MAY instead generate a fresh cryptographic handshake message and start
+packet numbers from 0.  This ensures that new 0-RTT packets will not use the
+same keys, avoiding any risk of key and nonce reuse; this also prevents 0-RTT
+packets from previous handshake attempts from being accepted as part of the
+connection.
+
 
 ### Minimum Packet Size