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

[Eric Rescorla <[e-mail]>]

Does this need to be a 1.0 feature?

On Fri, Sep 27, 2019 at 12:13 PM Ted Hardie <[e-mail]> wrote:

> Hi Nick,
>
> Two points in addition to the privacy issue already raised make me concur
> with Roberto that this should be v2 or later.  The first is this:
>
> "Negotiating or advertising features is something multiple
> applicationswill need to do and is not a feature specific to H3."
>
> Absolutely true, but there is also a fairly large variability in how
> applications do this.  If we design something now that works for H3, it may
> very well be sub-optimal or useless for later application targets.  Getting
> something general enough to handle DNS, WEBRTC,  SMTP, plus the various
> flavors of IoT protocols I've heard as targets hoping to move to QUIC is
> going to take time and care, and it will block completion of v1.
>
> The second is this:
>
> *The other downside is that if too much data is put in application
> parameters, it could cause the number of packets for a client or server’s
> flight to go from N to N+1, which would increase the chance of head of line
> blocking.
>
> Depending on what counts as application parameters, this could be more
> than N+1.  Someone running NETCONF over QUIC, for example, would be using a
> fairly verbose syntax in which each parameter is a full URN.
>
> regards,
>
> Ted Hardie
>
>
> On Thu, Sep 26, 2019 at 5:52 PM Nick Harper <nharper=
> [e-mail]> 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.
>>
>> Negotiating or advertising features is something multiple applications
>> will need to do and is not a feature specific to H3. Whatever we do in
>> H3 will likely be copied by other applications using QUIC. By
>> providing a general mechanism in QUIC transport, we provide
>> applications with a consistent way of achieving this goal. QUIC has a
>> design pattern of collapsing multiple layers into one to save on round
>> trips (e.g. combining crypto and transport handshake); this fits in
>> with that pattern.
>>
>> Using application parameters for H3 SETTINGS clears up some issues. H3
>> doesn’t need to specify that an endpoint shouldn’t wait for its peer’s
>> SETTINGS since they’ve already arrived. Likewise, there is no
>> confusion about whether SETTINGS arriving after session tickets are
>> bound to the session tickets; SETTINGS arrives before the tickets and
>> the client doesn’t need to wait for the receipt of SETTINGS to bind
>> them to the ticket. It also simplifies the server binding SETTINGS to
>> the ticket since that is done as part of binding transport parameters
>> to the ticket.
>>
>> This also provides opportunities for future features. Since the
>> exchange of SETTINGS occurs before application data, a new feature
>> doesn’t need to be specified in a way to provide an upgrade path from
>> “vanilla” H3 to something including this feature, and instead be
>> guaranteed that the new feature can be used for the entire connection.
>>
>> Without application parameters, each application that needs to
>> advertise or negotiate application settings needs its own mechanism to
>> do so. This would result in multiple transport parameters or
>> extensions leading to duplication of work and layering violations.
>> Applications could instead exchange these settings in application
>> data, meaning that each application needs to define the semantics of
>> application data received before and after the settings have been
>> exchanged, as H3 currently does.
>>
>> There is already a demonstrated need for an application parameters
>> mechanism in the QUIC handshake. One example is
>> https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 which is
>> currently using a “web_accepted_origins” transport parameter but could
>> easily use an application parameters mechanism instead.
>>
>> I see two downsides to this proposal. The first is that the client’s
>> application parameters are sent in the clear. Application designers
>> will need to make a decision of how much they want to use this
>> functionality (they could limit what is sent by the client or only use
>> application parameters in the server direction). For H3, there are
>> only three SETTINGS, QPACK_MAX_TABLE_CAPACITY, QPACK_BLOCKED_STREAMS,
>> and MAX_HEADER_LIST_SIZE, which do not reveal any information about
>> the user or the server they are connecting to and are likely constant
>> per H3 implementation.
>>
>> The other downside is that if too much data is put in application
>> parameters, it could cause the number of packets for a client or
>> server’s flight to go from N to N+1, which would increase the chance
>> of head of line blocking.
>>
>> Related issues:
>> https://github.com/quicwg/base-drafts/issues/2790: Binding settings
>> into session tickets
>> https://github.com/quicwg/base-drafts/issues/2945: When to send the
>> SETTINGS frame
>> https://github.com/quicwg/base-drafts/issues/2783: Consider making
>> SETTINGS part of the control stream header
>> https://github.com/quicwg/base-drafts/issues/436: Move SETTINGS into
>> TLS Handshake
>>
>>