Subject: [quicwg/base-drafts] 0-RTT flow control lmits can't be increased (#2360)

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Jan 2019 13:42:38 -0800

In #2344, we discuss what can be sent in 0-RTT.  We realized that while in theory the client should not be accepting 1-RTT packets from the server and then sending 0-RTT, there is nothing to prevent that.

The proposed defense is to prohibit the client from using increased limits (on flow control or streams) that it might have learned from 1-RTT packets.  This ensures that 0-RTT - the parts of the connection that might be replayed - are strictly limited to the initial limits.  Like many other things, we would require the client not to exceed this limits and merely allow the server to enforce that, in case the server was not inclined to do so.

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

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 22 Jan 2019 15:30:28 -0800

:+1:

-- 
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/2360#issuecomment-456606152

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Jan 2019 16:52:15 -0800

Tokyo conclusion: we will prohibit the client from sending more than the remembered flow control limits (nothing from the new transport parameters or 1-RTT packets can be used to increase the window).  Some debate about requiring servers to enforce this requirement, decided not to require the generation of a connection error.

-- 
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/2360#issuecomment-459171200