[quicwg/base-drafts] HTTP SETTINGS and 0-RTT (#1541)

[Mike Bishop <[e-mail]>]

The current draft language, after previous discussion, says this:

> When a 0-RTT QUIC connection is being used, the client’s initial requests will be sent before the arrival of the server’s SETTINGS frame. Clients MUST store the settings the server provided in the session being resumed and MUST comply with stored settings until the server’s current settings are received.
> 
> Servers MAY continue processing data from clients which exceed its current configuration during the initial flight. In this case, the client MUST apply the new settings immediately upon receipt.

That means the client can accidentally (or maliciously) exceed the server's values during the 0-RTT phase.  It means clients have to tolerate having settings reduced after the fact -- discovering your QPACK table is too big, or you've employed too many placeholders in describing your priority tree.  And there's no synchronization of when the server's values for this connection take effect, because we removed the synchronization mechanisms when we decided that SETTINGS are sent once and fixed for the lifetime of the connection.  If the server decides not to honor the MAY and closes the connection for bad behavior, the client might not have actually seen the SETTINGS frame (reliable delivery isn't guaranteed when the connection gets closed!) and so doesn't even know what it violated.  Its only recourse is to assume that its cached settings are bad and not do 0-RTT next time, and it seems a pity to require that level of fallback simply from a configuration change.

Are we ***really*** sure this is what we want?  Wouldn't it be cleaner to simply say that you can only accept 0-RTT if you're willing to guarantee that your settings will be equally or more permissive than the ones the client has remembered?  Yes, this means that settings will need to specify what counts as equally or more permissive when it's not obvious, but that text seems like a small price to pay.

The larger price is that the HTTP layer will have to examine what settings the client has associated with its session ticket and participate in the decision to accept 0-RTT.  It's a pain.  But is it more of a pain than what we have?  Particularly when the only way to identify a malicious client is to store the old settings with the ticket anyway and check that the client is following the rules as it understood them from last time?

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