Subject: Re: [quicwg/base-drafts] Server might be unable to complete handshake due to MAX_STREAM_DATA (#725)

From: Nick Banks <[email-masked]>
Date: Mon, 29 Jan 2018 21:38:34 +0000 (UTC)

Has there been any more progress on this front? A coworker of mine suggested another thing that we should take into account: OCSP stapling. That would further increase the size of the server's payload.

I feel like, at least for v1, we should have a way to make progress in these scenarios, even if we lose out on 0-RTT. @MikeBishop's suggestion make sense:

> "If it can't fit in N times the size of the client's packet, server MUST do source address validation before performing the large handshake."

But it doesn't fix the issue the server being blocked on the client's initial FC window. Maybe we always do a stateless retry if the server detects this issue and somehow communicates the minimum FC window size required in the retry?

-- 
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/725#issuecomment-361395362

---

From: Mike Bishop <[email-masked]>
Date: Mon, 29 Jan 2018 22:17:32 +0000 (UTC)

Exempting Stream 0 from stream flow control as well (until the handshake completes, or entirely) is probably the only real way out here.  You'd still want the requirement to do address validation to keep that from becoming an attack vector, though.

-- 
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/725#issuecomment-361406081