From 624b8376ec9eb755c293133f6721334ade27a989 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 22 May 2019 14:19:54 +0100 Subject: [PATCH 1/4] Clients use the same crypto handshake after Retry As agreed in London and Tokyo. Closes #2180. --- draft-ietf-quic-transport.md | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index dc044f6e8f..1412ea6f3c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3885,14 +3885,17 @@ the connection ID as part of its token validation logic (see The next Initial packet from the client uses the connection ID and token values from the Retry packet (see {{negotiating-connection-ids}}). Aside from this, the Initial packet sent by the client is subject to the same restrictions as the -first Initial packet. A client can either reuse the cryptographic handshake -message or construct a new one at its discretion. +first Initial packet. A client MUST use the same cryptographic handshake +message it includes in this packet. A server MAY treat a packet that +contains a different cryptographic handshake message as a connection or discard +it. 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 without constructing a new cryptographic handshake -message MUST NOT reset the packet number to 0 after a Retry packet; see -{{packet-0rtt}}. +packets to the connection ID provided by the server. A client MUST NOT change +the cryptographic handshake message it sends in response to receiving a Retry. +A client that sends additional 0-RTT packets without constructing a new +cryptographic handshake message MUST NOT reset the packet number to 0 after a +Retry packet; see {{packet-0rtt}}. A server acknowledges the use of a Retry packet for a connection using the original_connection_id transport parameter (see From 786cbf4ccfd1eaf5f593137bb91c49ceebd06902 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 22 May 2019 14:40:42 +0100 Subject: [PATCH 2/4] Keep the same packet numbers after Retry This isn't just for 0-RTT. --- draft-ietf-quic-transport.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 1412ea6f3c..d12f972e02 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3893,9 +3893,9 @@ it. 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 MUST NOT change the cryptographic handshake message it sends in response to receiving a Retry. -A client that sends additional 0-RTT packets without constructing a new -cryptographic handshake message MUST NOT reset the packet number to 0 after a -Retry packet; see {{packet-0rtt}}. + +A client MUST NOT reset the packet number to 0 for any packet number space after +processing a Retry packet; {{packet-0rtt}} contains more information on this. A server acknowledges the use of a Retry packet for a connection using the original_connection_id transport parameter (see From 39786f45a86abe156559b4bc586f3816e71c9f88 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 22 May 2019 14:49:47 +0100 Subject: [PATCH 3/4] Missed a critical word --- draft-ietf-quic-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index d12f972e02..93e8381084 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3887,8 +3887,8 @@ from the Retry packet (see {{negotiating-connection-ids}}). Aside from this, the Initial packet sent by the client is subject to the same restrictions as the first Initial packet. A client MUST use the same cryptographic handshake message it includes in this packet. A server MAY treat a packet that -contains a different cryptographic handshake message as a connection or discard -it. +contains a different cryptographic handshake message as a connection error or +discard it. 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 MUST NOT change From 6e2b7e10de29ec7b931c7afa40015d2d0b4db4ce Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 11 Jun 2019 19:29:32 +1000 Subject: [PATCH 4/4] s/to 0// as redundant --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 93e8381084..0e88e505d8 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3894,7 +3894,7 @@ 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 MUST NOT change the cryptographic handshake message it sends in response to receiving a Retry. -A client MUST NOT reset the packet number to 0 for any packet number space after +A client MUST NOT reset the packet number for any packet number space after processing a Retry packet; {{packet-0rtt}} contains more information on this. A server acknowledges the use of a Retry packet for a connection using the