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