Re: [quicwg/base-drafts] When to send the SETTINGS frame (#2945)

[David Benjamin <[e-mail]>]

@martinthomson I'm probably just confused, but how does #2958 add head-of-line blocking?

@janaiyengar Saying that implementations should send the SETTINGS frame ASAP doesn't address the problems the asymmetry is trying to solve. Perhaps QUIC does not wish to solve the problem at all, but it's not the case that "simply" sending SETTINGS ASAP fixes things.

There's also a lot of hidden complexity to the status quo:

* What does the client do when it receives NST before SETTINGS? The spec needs to discuss this or it is incomplete.
* The TLS document needs to mention that the protocol atop QUIC may hook into it interestingly. I suspect this issue would have been noticed sooner were this mentioned! A TLS implementer trying to understand the implications of QUIC is unlikely to read the HTTP document very carefully.
* The server must remember the SETTINGS frame it sent in the ticket, so it can emit the delta SETTINGS encoding ("The server MAY omit settings from its SETTINGS frame which are unchanged from the initial value") and decide if its current SETTINGS frame allows 0-RTT at all ("If 0-RTT data is accepted by the server, its SETTINGS frame MUST NOT reduce any limits or alter any values that might be violated by the client with its 0-RTT data"). This means you *already* have asymmetry. Your TLS library will have a `SetServerSETTINGSFrame()` function, but not a `SetClientSETTINGSFrame()`. It will also need to pick one of (a) conservatively require exact match for 0-RTT, (b) know how to parse HTTP/3 SETTINGS frames, or (c) expose a callback interface.
* Conversely, either the client remembers the server SETTINGS frame entirely out-of-band, or the TLS library does it. If the former (note another asymmetry: out-of-band isn't an option on the server if using stateless tickets), you need to deal with the calling code and TLS library disagreeing on whether a session supports 0-RTT. If the latter, you now need additional API surface for querying the remembered SETTINGS frame, configuring the newly-received one post-handshake, plus the async handling.
* There is an asymmetry between 0-RTT and 1-RTT. The client needs to check that one arbitrary SETTINGS frame indeed doesn't reduce limits from some other arbitrary one. This is otherwise not necessary because 1-RTT connections begin at the initial state, not the previous state.

Some of these (e.g. the last one) aren't fixed by #2958, but they at least reduce to transport parameters, and the worst of it (ordering problems) is gone.

(For completeness, there's a third option, which is to not stick the SETTINGS frame into the ticket at all. This fixes everything, but it means you get your SETTINGS frame slightly later.)

QUIC is already quite invasive when it comes to the QUIC/TLS interface. It complicates the whole ecosystem around QUIC and compromises QUIC's ability to pick up TLS changes. (Did everyone remember their QUIC/TLS record-layer interfaces need to express record-level padding for ESNI? It's not obvious at first glance.) That ability is critical; if TLS over QUIC is ever unable to meet TLS over TCP's baseline as we evolve it with ESNI, post-quantum algorithms, etc., browsers will need to disable QUIC to avoid downgrade attacks.

Let's try to trim away invasive dependencies when it doesn't buy much. Remember, complexity at component boundaries costs much more than complexity within a component.

-- 
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/2945#issuecomment-519338186