Re: Add application parameters to QUIC handshake and use it for H3 SETTINGS

[Nick Harper <[e-mail]>]

On Thu, Sep 26, 2019 at 7:48 PM Christian Huitema <[e-mail]> wrote:
>
> On 9/26/2019 2:51 PM, Nick Harper wrote:
>
> > I propose introducing application parameters to the QUIC handshake and
> > using this new mechanism for H3 SETTINGS instead of sending them as
> > the first thing in the control stream. Application parameters would
> > allow applications using QUIC to advertise or negotiate
> > application-specific parameters during the cryptographic and transport
> > handshake. It would guarantee that the client and server have
> > exchanged their application parameters once the handshake is complete.
> >
> > Specifically, I’m proposing a new “application_layer_parameters”
> > transport parameter, which when sent by the client is a series of ALPN
> > identifiers with an opaque blob of application parameters per
> > identifier, and when sent by the server is a single opaque blob of
> > application parameters for the application identified in the ALPN
> > extension.
>
>
> I am a tad concerned with the privacy aspects of this proposal, at least
> on the client side. Currently, the settings frame is sent encrypted in
> 0-RTT or 1-RTT packets. With your proposal, it would be sent in
> clear-text, allowing very easy fingerprinting of clients.
>
> -- Christian Huitema
>

Yes, this does provide a fingerprinting vector. Transport Parameters
also provide a fingerprinting vector with about 10 parameters that
could reasonably be used for fingerprinting, compared to the 3 we have
in H3. The nature of both of those sets of parameters is that they'd
likely fingerprint implementations but not individual clients.

In terms of the application parameters design, individual applications
can choose whether or not they want to use them in the client flight
or just the server flight. We could keep client SETTINGS in the
control stream and only put server SETTINGS in application parameters.