Subject: Re: [quicwg/base-drafts] Don't amplify 0-RTT (#1616)

From: ianswett <[email-masked]>
Date: Wed, 01 Aug 2018 17:36:17 -0700

ianswett commented on this pull request.

> @@ -1896,6 +1896,13 @@ dynamically calculate the expiration time.  It is also unlikely that the client
 port number is the same on two different connections; validating the port is
 therefore unlikely to be successful.
 
+Even when a token is valid, a server SHOULD limit the amount of data that it
+sends toward a client in response to 0-RTT data.  Spoofing of source addresses
+and replays of 0-RTT handshake messages can cause tokens to appear to be valid
+when they are not.  No specific recommendation is made regarding the ratio of
+data sent to received, though it is unlikely to be necessary to send more than
+the initial congestion window.

I think it's fairly likely it may be necessary to send more than the IW, but I think we should advise limiting the amount of data sent to the IW.  I think this just falls out of the recovery doc, since the recovery doc specifies an initial window of 10 packets, so I'm not completely sure this is necessary?

-- 
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/1616#discussion_r207072319

---

From: Martin Thomson <[email-masked]>
Date: Wed, 01 Aug 2018 17:43:38 -0700

martinthomson commented on this pull request.

Yeah, this is why it is worded so loosely.  Without this advice, the risk seems to be limited to the server receiving a spoofed ACK for the ServerHello and sending that much more in response, but that's only one more packet than the IW, so it's hardly earth-shattering.

Given that this is largely dictated by congestion controller design (IW specifically), is this really a change we need to implement?  Should we instead close #1309 with no 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/pull/1616#discussion_r207073216

---

From: ianswett <[email-masked]>
Date: Wed, 01 Aug 2018 17:45:03 -0700

I'm fine with just closing #1309

-- 
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/1616#discussion_r207073391

---

From: Martin Thomson <[email-masked]>
Date: Wed, 01 Aug 2018 17:49:03 -0700

@ekr?

-- 
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/1616#discussion_r207073862

---

From: ekr <[email-masked]>
Date: Thu, 02 Aug 2018 04:48:34 -0700

ekr commented on this pull request.

Concur. Let's close #1309

Sure, but when I raised this issue I didn't have this fix in mind. There are two cases.

In case 1, there is no valid token, in which case you should follow the same rules for non-HS data as HS data: 3 packets.

In case 2, there is a valid token, in which case YOLO.

-- 
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/1616#pullrequestreview-142349835

---

From: Martin Thomson <[email-masked]>
Date: Thu, 02 Aug 2018 15:30:02 -0700

Closed #1616.

-- 
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/1616#event-1768801113