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

[Nick Harper <[e-mail]>]

I think @janaiyengar frames this issue well, that we don't currently have an application handshake embedded in the crypto+transport handshake. #2958 is close to providing a general mechanism for an application handshake embedded in the crypto+transport handshake. The change necessary to that PR to provide all of the application handshake would be to allow specifying different application_layer_parameters for different alpns. The caveat is that the client-sent application layer params are sent in the clear, but this might not be an issue. (For example, transport params are sent in the clear by the client even though they could be delayed a round-trip to have them encrypted, and an application could make the analysis that the client-sent part of its handshake is not sensitive information that needs to be encrypted because it is similar to transport params.)

Since the application handshake mechanism in #2958 doesn't impose any restrictions on how the application uses it, we can use it in H3 only for the server->client direction. Having just half of the embedded application handshake seems better than not using it at all. In addition to the benefits for #2790, sending the server's SETTINGS in the handshake means both sides can know that it comes before any server-sent application data (and before client-sent application data on non 0-RTT connections).

Regardless of the outcome on this issue, I think #2972 to send complete SETTINGS instead of only the ones that have changed is a good idea, and we can merge that one while still figuring out what to do here.

-- 
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-524078106