From d24747212e2938deb97a95adbc6f6edcdee28861 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 1 Aug 2018 10:34:01 +1000 Subject: [PATCH] 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 | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index bfe1492bf6..a0132e3a89 100644 --- a/draft-ietf-quic-transport.md +++ b/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