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

[Christian Huitema <[e-mail]>]

On 11/5/2023 4:43 PM, Watson Ladd wrote:
> 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.

That's why it would be better to place the data in the address 
validation tokens, which are explicitly tied to IP addresses.
(Watson: address validation tokens are defined in section 8 of RFC 9000. 
The primary goal is defend against the QUIC equivalent of SYN Attacks, 
but the servers can use them however they see fit.)

-- Christian Huitema