Subject: Re: [quicwg/base-drafts] Clients use the same crypto handshake after Retry (#2746)

From: ianswett <[email-masked]>
Date: Mon, 10 Jun 2019 10:21:13 -0700

ianswett approved this pull request.

 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

```suggestion
packets with the connection ID provided by the server.  A client MUST NOT change
```

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

Said below, BTW.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2746#pullrequestreview-247736216

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 10 Jun 2019 22:20:02 -0700

kazuho commented on this pull request.

LGTM modulo the point below.

 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 MUST NOT reset the packet number to 0 for any packet number space after

Do we need to stay "to 0"?

I think it'd be better to just omit "to 0", because resetting the packet number does not necessary mean that it goes to zero. It is totally reasonable for an endpoint to start it's packet number from one.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2746#pullrequestreview-247955308

---

From: MikkelFJ <[email-masked]>
Date: Tue, 11 Jun 2019 00:26:27 -0700

mikkelfj commented on this pull request.

It says that you must not reset to zero. It does not matter if you do not necessarily reset to 0 if you sometimes can. I'm not sure why 0 is important in higher packer number spaces, but if it is, it must be stated.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2746#discussion_r292310826

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Jun 2019 02:50:28 -0700

@martinthomson pushed 1 commit.

6e2b7e10de29ec7b931c7afa40015d2d0b4db4ce  s/to 0// as redundant

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2746/files/39786f45a86abe156559b4bc586f3816e71c9f88..6e2b7e10de29ec7b931c7afa40015d2d0b4db4ce

---

From: Martin Thomson <[email-masked]>
Date: Tue, 18 Jun 2019 15:10:47 -0700

Merged #2746 into master.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2746#event-2422390310