Merge pull request #2831 from marten-seemann/pn-after-retry

fix effect of Retry on 0-RTT packets

draft-ietf-quic-transport.md

@@ -3758,12 +3758,11 @@ After a client receives a Retry 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 packet unless the client also regenerates the cryptographic handshake
-message.  Sending packets with the same packet number in that case is likely to
-compromise the packet protection for all 0-RTT packets because the same key and
-nonce could be used to protect different content.
+A client MUST NOT reset the packet number it uses for 0-RTT packets, since the
+keys used to protect 0-RTT packets will not change as a result of responding to
+a Retry packet.  Sending packets with the same packet number in that case is
+likely to compromise the packet protection for all 0-RTT packets because the
+same key and nonce could be used to protect different content.
 
 Receiving a Retry packet, especially a Retry that changes the connection ID used
 for subsequent packets, indicates a strong possibility that 0-RTT packets could
@@ -3774,12 +3773,6 @@ 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.
 
-A client SHOULD 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.
-
 A client MUST NOT send 0-RTT packets once it starts processing 1-RTT packets
 from the server.  This means that 0-RTT packets cannot contain any response to
 frames from 1-RTT packets.  For instance, a client cannot send an ACK frame in a