On Fri, Nov 3, 2023 at 8:45 AM Lucas Pardue <[email protected]> wrote: > > Hi folks, > > I'm still trying to come up to speed on this spec. But when I've thought > about it a little, its seemed very natural to associate the BDP frame > (contents) with the TLS session. We already have a lot of text about TLS > session resumption in QUIC. It feels like there is already a template design > with HTTP/3 - a server sends SETTINGS to tell a client something unique about > the active QUIC connection. RFC 9114 section 7.2.4.2 [1]states > > > When a 0-RTT QUIC connection is being used, the initial value of each > > server setting is the value used in the previous session. Clients SHOULD > > store the settings the server provided in the HTTP/3 connection where > > resumption information was provided, but they MAY opt not to store settings > > in certain cases (e.g., if the session ticket is received before the > > SETTINGS frame). A client MUST comply with stored settings -- or default > > values if no values are stored -- when attempting 0-RTT. Once a server has > > provided new settings, clients MUST comply with those values.¶ > > So with a bit of massaging, if we can link BDP frame to session resumption. > we know that it is based on a previous trust relationship.
I'd prefer not to incorporate user application related data (which QUIC info would be) in TLS resumption tickets. There is not a great way to do this, and particularly as BDP can vary over time so the TLS layer would have to send more tickets. Not fatal, but more coupling than I think is ideal. > > Is there any scenario where BDP frame would want to be used without TLS > resumption? > > Cheers > Lucas -- Astra mortemque praestare gradatim
