Re: [quicwg/base-drafts] RESET_STREAM should be allowed in 0-RTT packets (#2344)

[Martin Thomson <[e-mail]>]

Is the concern here about a denial of service attack on the server?  That is, the extra frames that it might receive, which aren't really limited in any way by flow control or other such limitations, might cause it to do too much work?

This doesn't sound that interesting to me.  There is always a risk when you accept 0-RTT that the client or data is bad.  As @MikeBishop points out, you shouldn't be accepting the same 0-RTT multiple times.  The recommendations in TLS 1.3 provide some tips on how to avoid that.   But even if your server configuration doesn't allow you to detect that and stop it, the work you expend on 0-RTT packets is a cost that you take on.  And you take on that work with the understanding of the associated risk of replay.  Clients can always send far more stuff than you are prepared to process; servers just need to make the call.  For instance, rejecting 0-RTT would be my first response to increasing server load.

If a client chooses to send 0-RTT when 1-RTT keys are available to it, maybe we can allow servers to cut them off.  That's maybe hard to police, but simple things like exceeding initial flow control might be detectable.  Even if the server has provided more credit, the client should still be operating within the initial window for 0-RTT.

-- 
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/2344#issuecomment-456536446