Subject: [quicwg/base-drafts] Add application parameters to QUIC handshake and use it for H3 SETTINGS (#3086)

From: Nick Harper <[email-masked]>
Date: Thu, 10 Oct 2019 14:51:52 -0700

This was brought up on the list: https://mailarchive.ietf.org/arch/msg/quic/0ibfDvI7GndUOf3eqQZXf0aEQLA.

The summary of the proposal is to provide a place in the crypto/transport handshake where the application can negotiate application parameters in the same round trip as the crypto handshake. The purpose of this is to ensure that when the first application data packet is sent (under 0-RTT or 1-RTT keys), the endpoint sending it knows how its peer will interpret it, instead of needing to spend a round trip of application messages to negotiate settings/parameters for the application.

The other part of this proposal is to move H3 SETTINGS into this new application parameters mechanism.

My summary of the thread so far (please correct me if it's incomplete or inaccurate) is that some people want this to be considered as a v2 feature: there are concerns about getting a design that will work for all future protocols that might run on QUIC; there are also concerns about working on this delaying v1.

I think that the application parameters mechanism (at least in v1) doesn't need to solve the problem perfectly for every conceivable application, but simply needs to be "good enough" for most applications. I also think that some of the complexity (e.g. some application protocols being particularly verbose in their negotiation) will need to be solved in the spec for running a specific application over QUIC.

Whatever we do in v1 for H3 will likely be the model for other applications using QUIC (in v1 or future versions of QUIC).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3086

---

From: ianswett <[email-masked]>
Date: Thu, 10 Oct 2019 18:00:58 -0700

To me, there are two clear approaches:
 1) Add application negotiation to the handshake
 2) Make the application implement negotiation

Currently QUIC and HTTP/3 use the 2nd approach, and you're suggesting the 1st.

If those are the only two (reasonable) options, then adding application parameters allows HTTP/3 to do 1, while still allowing other applications to do 2, if they choose.  This provides more options for future applications, not fewer in my opinion.

Strictly speaking, I don't think this is necessary for v1, but I think this is something we'll want soon and I believe it is a net reduction in complexity for HTTP/3(please tell me if I'm wrong about that).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3086#issuecomment-540856767

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 Oct 2019 19:58:27 -0700

I think that Ian's assessment is broadly correct.  The downsides of the move, are that it increases the complexity of the transport by about the same, if not more, than it helps h3.  And it's not clear that a simple pair of declarations (this doesn't work as a negotiation when you are generically useful for other protocols.

The limitations of the mechanism - specifically regarding confidentiality - of a mechanism that uses transport parameters or similar aren't nice for a generic mechanism.  If I was inclined toward a fix, then I would prefer something along the lines of what @kazuho suggested elsewhere, which could involve more encryption, but also more complexity with no real guarantee of the resulting mechanism being generically useful.

That's why I'm firmly in the `v2` camp here.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3086#issuecomment-540879423

---

From: MikkelFJ <[email-masked]>
Date: Thu, 10 Oct 2019 22:45:47 -0700

@nharper I believe you forgot to mention that early settings are not protected which can lead to privacy concerns both in terms of fingerprinting (but it has been argued that this is no worse than what already is), and in terms of actually reading the data. The last part is a concern because we already have problems with host names not being protected properly in the current form. You could encrypt early parameters with a symmetric key that is only learned post handshake, but I'm not sure if you can do this without introducing delays.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3086#issuecomment-540917489

---

From: Mike Bishop <[email-masked]>
Date: Fri, 11 Oct 2019 09:40:20 -0700

As discussed on #2945, I think the complexity is in having something in the transport parameters (the server settings) that depends on the protocols selected in the ALPN extension, which in turn depends on the set of possibilities the client offered.  There's currently nothing that has a similar chain of dependencies.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3086#issuecomment-541137374

---

From: Nick Harper <[email-masked]>
Date: Fri, 11 Oct 2019 13:42:20 -0700

I disagree that moving this from H3 to the transport makes the transport more complicated than it simplifies H3.

The additional complexity to the transport is setting on the client a map of ALPN identifiers to application layer blobs of data (opaque to the transport), on the server setting a blob of data based on the ALPN, and getting the params sent by the peer.

Making this change to H3 means we remove the complexity of migrating from the default SETTINGS for a connection to the SETTINGS received some time later. It also reduces the complexity of binding SETTINGS to the NST for 0-RTT: on the server the SETTINGS is now in TP which already needs to be remembered, and the client now doesn't need to wait for SETTINGS to arrive after a NST to store them. It also removes the edge case where a client might do 0-RTT resumption without any remembered SETTINGS. This also removes the need for an H3 client to decide whether to send a request under default SETTINGS or wait for SETTINGS to arrive from the server.

I also disagree that this change introduces new meaningful complexity to generating the server's transport parameters message. The server needs to read the client's ALPN list and choose one that the server is configured for (this isn't new), and now it needs to when choosing the ALPN also choose the appropriate application parameters to go with that ALPN. For H3, the server will need those SETTINGS shortly after in the handshake when sending a NST so it can bind the SETTINGS to the NST. Likely the SETTINGS are constant, so it can be configured before accepting the connection with what the SETTINGS are and do a lookup to get those SETTINGS when sending ALPN.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3086#issuecomment-541216958

---

From: Nick Harper <[email-masked]>
Date: Fri, 11 Oct 2019 14:13:24 -0700

Regarding the confidentiality of this mechanism:

I am assuming (perhaps incorrectly) that the contents advertised in the client's application parameters are no more confidential than transport parameters. In H3, both the transport parameters and SETTINGS are effectively constant per implementation - any identifying bit leaked by the H3 SETTINGS is also leaked by the transport parameters. My assumption is that other future applications using this mechanism will be similar in the amount of (non) leakage, but that can be analyzed on a per-application basis.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3086#issuecomment-541226138

---

From: hardie <[email-masked]>
Date: Mon, 14 Oct 2019 15:34:01 -0700

On Fri, Oct 11, 2019 at 2:13 PM Nick Harper <[email-masked]>
wrote:

> I am assuming (perhaps incorrectly) that the contents advertised in the
> client's application parameters are no more confidential than transport
> parameters. In H3, both the transport parameters and SETTINGS are
> effectively constant per implementation - any identifying bit leaked by the
> H3 SETTINGS is also leaked by the transport parameters. My assumption is
> that other future applications using this mechanism will be similar in the
> amount of (non) leakage, but that can be analyzed on a per-application
> basis.
>
> This definitely needs to be per-application and may need to be per
parameter.  If you treat the DNS client subnet as an application parameter
for DNS over QUIC, for example, the implications may be much more privacy
sensitive than for other EDNS0 parameters.

Ted

> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/3086?email_source=notifications&email_token=AAKVXZDWUYVNFQ2E5TAW7ODQODT67A5CNFSM4I7SPSU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBBHJGQ#issuecomment-541226138>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAKVXZFXDQRJ32OEVYHAOCDQODT67ANCNFSM4I7SPSUQ>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3086#issuecomment-541960573

---

From: Nick Harper <[email-masked]>
Date: Mon, 14 Oct 2019 17:50:32 -0700

I've updated https://github.com/quicwg/base-drafts/pull/2958 with how this mechanism might be specified.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3086#issuecomment-541988465

---

From: Mike Bishop <[email-masked]>
Date: Thu, 17 Oct 2019 14:41:50 -0700

Discussed in Cupertino.  We *will not* make this change in QUIC v1.  We will make a feature request to TLS for encrypted client-to-server extensions.  A mapping over a QUIC version that requires this TLS feature will use it for SETTINGS.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3086#issuecomment-543373506

---

From: Mike Bishop <[email-masked]>
Date: Thu, 17 Oct 2019 14:42:50 -0700

Closed #3086.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3086#event-2722855042