Subject: Should server enforce post-Retry packet numbering?

From: Dmitri Tikhonov <[email-masked]>
Date: Fri, 7 Aug 2020 09:54:11 -0400

Hello,

In a couple of threads on Slack, Lars reminded me of an interesting
MUST NOT in the transport draft:

" A client MUST NOT reset the packet number for any packet number space
" after processing a Retry packet; Section 17.2.3 contains more
" information on this.

This made me wonder whether the server should check that the client
indeed did not reset the packet number.  This is possible to do by
including the packet number into the Retry token and then comparing
this value with the number of the packet that carries the token back.

I could not find such SHOULD in the draft.  Should it be included?
E.g. "The server SHOULD abort the connection if it detects that packet
numbers were reset upon Retry."

  - Dmitri.

---

From: Marten Seemann <[email-masked]>
Date: Sat, 8 Aug 2020 07:47:12 +0700

I'm not sure if I'd increase the size of the token for this check in my
implementation, but if you don’t care about a few extra bytes, it probably
won’t hurt to perform this check.
I'm a bit skeptical if a SHOULD is warranted here though, as the worst that
can happen is a nonce reuse for a key that's publicly known anyway. Of
course, this might change once a client uses ECH or some kind of version
aliasing.

That said, I just added a check for this on the interop runner (
https://github.com/marten-seemann/quic-interop-runner/pull/130). Clients
will now fail the Retry test if they don't increase the packet number on
Retry.

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 7 Aug 2020 18:31:08 -0700

I think a "can" is enough here. A client that doesn't respect this risks
running into a server that enforces this MUST NOT and shoots the
connection. Is there a reason to recommend it?

On Fri, Aug 7, 2020 at 5:47 PM Marten Seemann <[email-masked]>
wrote:

> I'm a bit skeptical if a SHOULD is warranted here though, as the worst
> that can happen is a nonce reuse for a key that's publicly known anyway. Of

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 10 Aug 2020 08:30:23 -0400

I opened issue 3989 [1] on GitHub.

  - Dmitri.

1. https://github.com/quicwg/base-drafts/issues/3989