Subject: [quicwg/base-drafts] Need to prevent amplification attack for any case where the server's response is big (#1309)

From: ekr <[email-masked]>
Date: Thu, 19 Apr 2018 18:39:34 -0700

S 4.4.3 says

```
If the server expects to generate more than three Handshake packets in response to an Initial packet, it SHOULD include a PATH_CHALLENGE frame in each Handshake packet that it sends. After receiving at least one valid PATH_RESPONSE frame, the server can send its remaining Handshake packets. Servers can instead perform address validation using a Retry packet; this requires less state on the server, but could involve additional computational effort depending on implementation choices.
```

However, there are two other cases where the server might generate >3 packets outside of the handshake:

* The application data protocol is a server speaks first protocol and it has a large banner it wants to send in 0.5 RTT
* The client is doing 0-RTT

There are ways to fix this, but it's not clear to me that the protocol actually documents them.

-- 
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/1309

---

From: Patrick McManus <[email-masked]>
Date: Fri, 20 Apr 2018 01:46:16 +0000 (UTC)

> 6.6.2.  Address Validation on Session Resumption

relevant?

-- 
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/1309#issuecomment-382938652

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Apr 2018 01:35:39 -0700

@mcmanus, yes.  @ekr, does that work for you?  Do we need to put a pointer in?

-- 
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/1309#issuecomment-384206616

---

From: janaiyengar <[email-masked]>
Date: Wed, 25 Apr 2018 15:49:19 -0700

I wonder if this text should be stronger, given that we rely on servers doing the right thing to avoid amplification attacks. This is an issue IMO with TFO deployments, and I worry that if we don't specify something here we may end up with careless implementations.

We can have recommendations around the expiration time, and around what information should be included and verified. I don't want to bikeshed on these values, but having something here is better than nothing I think.

-- 
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/1309#issuecomment-384457997

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Apr 2018 04:31:41 +0000 (UTC)

Yeah, we should be clearer about this, and more general.  PR wanted.

-- 
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/1309#issuecomment-385311491