Subject: [quicwg/base-drafts] Allow server to enforce port-Retry packet numbering (#3989)

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 10 Aug 2020 05:29:54 -0700

_(I first raised this issue on the [mailing list](https://mailarchive.ietf.org/arch/msg/quic/D59v8K4Zem5Kb2zjQWyKsA_v1eI/).)_

There is the following `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.
```

We should allow the server to abort the connection the the client violates this `MUST NOT`.  The server can do so by including the packet number into the Retry token and comparing against it when the client sends packets that carry the token.

-- 
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/issues/3989

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Aug 2020 17:48:16 -0700

I think that this might as well run through the design process.  It's borderline, because this is about enforcement of an existing MUST, which you might argue comes with an implicit MAY enforce, but we do need to agree on the requirement level.

Note that this isn't completely trivial to implement.  If a servers responds to packet 1 with Retry, it has to ignore packet 0 if it arrives with no token (or a NEW_TOKEN token).  That's already a requirement, but a poor implementation of this requirement will fail, likely with low enough probability that the error won't be detected, especially when it is hidden by Alt-Svc.

-- 
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/issues/3989#issuecomment-671660704

---

From: ianswett <[email-masked]>
Date: Mon, 10 Aug 2020 18:02:44 -0700

I agree this isn't trivial to enforce.  Which is why I favor "If you detect this, you SHOULD close the connection.", rather than any recommendation on detecting a violation.

-- 
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/issues/3989#issuecomment-671664330

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 10 Aug 2020 18:08:55 -0700

Aside from it not being trivial to enforce, I am not sure how much I like the idea of enforcing correctness for Initial packets. And that is because injection of Initial packets is the way for middleboxes to disrupt the connection.

IIRC, we have allowed endpoints to ignore suspicious Initial packets, and I tend to think that we do not need to suggest that an endpoint can (IMO needlessly) strict.

-- 
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/issues/3989#issuecomment-671666057

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 11 Aug 2020 05:42:58 -0700

> Note that this isn't completely trivial to implement. If a servers responds to packet 1 with Retry, it has to ignore packet 0 if it arrives with no token (or a NEW_TOKEN token). That's already a requirement

How would the server know to ignore packet 0 in a *Stateless* Retry?  I believe it would respond with another Retry packet instead.

-- 
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/issues/3989#issuecomment-671923127

---

From: Mike Bishop <[email-masked]>
Date: Tue, 11 Aug 2020 08:54:39 -0700

If it's not trivial, it's verging on trivial.  The "right" way to enforce this, as Dmitri notes, is to include the client's packet number in the Retry token.  Upon receipt of any token, if it is a retry token, the server checks whether the containing packet number is less than or equal to that stored in the token.  If it's not a retry token, no check is needed.  This is completely stateless, so if packets get reordered, nothing breaks.

As to the point of modifying Initial packets, that's true.  An attacker that can modify packets can always cause the handshake to fail; this is just another way.  To use this for disruption by injecting a packet, the attacker has to observe the client's Initial, the server's Retry packet, and then fabricate an Initial with a lower packet number.  Not a high bar, but an attacker that can observe the packets in both directions and inject packets can break things in many other ways, too.

I'm comfortable with MAY enforce (which I think is already implicit in a MUST NOT) at least, if people think one more integer encoded in the token is too high a bar for a stronger recommendation.

-- 
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/issues/3989#issuecomment-672037067

---

From: ianswett <[email-masked]>
Date: Tue, 11 Aug 2020 10:02:08 -0700

I'm also fine with MAY.  Honestly, I'm also fine with can.

I agree with Mike's comments that there are so many ways to interrupt the handshake at this stage, this is just another one, and likely not the easiest by far.

-- 
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/issues/3989#issuecomment-672094407

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 11 Aug 2020 15:55:59 -0700

I agree that it is unlikely that servers detecting this behavior would help MITM attackers. My concern was mostly from a consistency standpoint regarding what we write down in spec.

That said, I would not oppose to using a MAY here. It is already implied by the MUST NOT on the client-side, so to me it is an editorial change.

-- 
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/issues/3989#issuecomment-672337522