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

[Roberto Peon <[e-mail]>]

My preference would be to have a facility that would allow an application to ensure that some limited/constant-size data is in every packet that it sends until it gets an ACK.

This would allow control messages to be sent reliably, but avoid the HoL blocking issues.
The real issue that, I believe, we’re trying to solve here is to ensure that the first packet has everything in it that is needed for interpretation/settings, etc.

I also believe that this could be of use in a number of other HoL-prevention things.

It is my opinion that this is a QUICv2 feature, if it becomes something we’d want at all.
-=R

From: QUIC <[e-mail]> on behalf of Mikkel Fahnøe Jørgensen <[e-mail]>
Date: Thursday, September 26, 2019 at 10:55 PM
To: Christian Huitema <[e-mail]>, Nick Harper <nharper=[e-mail]>
Cc: IETF QUIC WG <[e-mail]>
Subject: Re: Add application parameters to QUIC handshake and use it for H3 SETTINGS

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]<mailto:nharper=[e-mail]>) wrote:
On Thu, Sep 26, 2019 at 7:48 PM Christian Huitema <[e-mail]<mailto:[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.