Re: Authentication in draft-kuhn-quic-bdpframe-extension

[Watson Ladd <[e-mail]>]

On Fri, Nov 3, 2023 at 8:45 AM Lucas Pardue <[e-mail]> 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