HTTP SETTINGS and 0-RTT

[MikeBishop]

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?

[martinthomson]

Yes, this:

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

I thought that we had that in transport, but I think that we missed something in the translation to the HTTP mapping.

[MikeBishop]

Did some spelunking in git history. In Tokyo, transport decided to permit the server to ignore overruns and HTTP followed suit. Transport later decided to change to the increase-only model, but HTTP never adopted that change.

I haven't found discussion about whether that was intentional; I seem to recall that it was, but if so, I think that was a mistake. If not, it was an oversight.