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

[David Schinazi <[e-mail]>]

Additionally, the current status quo makes it hard to have SETTINGS
play nicely with 0-RTT. Fixing this is important to deploying IETF QUIC.
We're chartered to produce a protocol with fast connection establishment,
and if we fail to negotiate options and extensions nicely with that, we'll
harm extensibility long-term and cause deployment of damaging workarounds.

David

On Tue, Oct 1, 2019 at 4:41 PM Nick Harper <nharper=
[e-mail]> wrote:

> I think it loses most of its utility if it's not a v1 feature. The
> main motivation for the feature is to simplify application protocols.
> At the time that v2 is introduced and application protocols are being
> specified to use it, existing application protocols will already have
> an application-specific way to negotiate params, so they will continue
> to use that instead of using both the existing application-specific
> mechanism (for v1) and v2-only application parameters feature (for
> v2+). (I'm assuming that as applications switch from using QUIC v1 to
> QUIC v2, it will be like upgrading H2 from TLS 1.2 to TLS 1.3, instead
> of like upgrading H2 to H3.)
>
> On Tue, Oct 1, 2019 at 1:51 PM Eric Rescorla <[e-mail]> wrote:
> >
> > 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
> >>>
>
>