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

[Ian Swett <[e-mail]>]

I agree that there is a privacy concern on the client side, but I don't
believe adding HTTP/3 SETTINGS makes it meaningfully worse than the
existing design.  As Nick said, the existing 10 transport params are likely
to have a lot more variability among implementations.  If we think that's a
real problem, then I think we'd do best to solve the general issue that
client transport params aren't encrypted.

I like this because it fits better with the overall design of QUIC where
we've combined transport, crypto and application handshake into one
optimized step.  I also think it'll make implementations simpler and it'll
be more likely QPACK will be used on early requests.

On Fri, Sep 27, 2019 at 1:55 AM Mikkel Fahnøe Jørgensen <[e-mail]>
wrote:

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

When connecting with 0-RTT, you must remember past transport params and use
those until the new transport parameters arrive.

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