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

[Mikkel Fahnøe Jørgensen <[e-mail]>]

Not arguing against the usefulness of such a feature, and aside from
already mentioned privacy issues:

It seems to be possible to facilitate a man-in-the-middle attack on
application parameters unless the application takes counter-measures which
would complicate matters and likely introduce delays anyway.

I also wonder how this would work with 0-RTT since it cannot be assumed
that application parameters would be remembered across connenctions.


On 27 September 2019 at 06.55.02, Nick Harper (
nharper=[e-mail]) wrote:

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.