Subject: Re: [TLS] ALPS and TLS 1.3 half-RTT data

From: Cory Benfield <[email-masked]>
Date: Mon, 1 Feb 2021 13:46:00 +0000

On Fri, 29 Jan 2021 at 23:38, David Benjamin <[email-masked]> wrote:
>
> Hi all,
>
>
> Thanks all for the feedback. I’ve tried to address it below, but there's a lot of text, so please let me know if I’ve missed or misunderstood any of your points.
>
>
> Cory commented on SETTINGS_[HQ]PACK_ENABLE_STATIC_TABLES in draft-vvv-httpbis-alps-00. I agree that is odd. We’ve uploaded a draft-01 that drops it.
>
>
> Cory also wrote:
>
> > I think the document does a good job laying out the difficulties with
>
> > half-RTT data, but it didn't convince me that ALPS is easier for H2.
>
>
> To clarify, are you unconvinced that ALPS is easier than leaving H2 alone, or that ALPS is easier than solving this problem with half-RTT? The document’s aim is the latter. Your comment in Martin’s thread reads to me like you agree with this. Am I interpreting that correctly? (I think draft-thomson-httpbis-h2-0rtt roughly corresponds to Section 2.3 of my document. Something like it would be necessary, but not sufficient, to solve this with half-RTT.)
>
>
> As to leaving H2 alone, doing nothing is indeed generally easier than doing something. But this is perhaps not a useful criteria. :-) The question is what’s the benefit of solving the problem. My interest is in the privacy benefits of rethinking content negotiation. Victor has use cases around WebTransport. The document cites some other uses.

I am unconvinced that ALPS is easier than leaving H2 alone _and_ that
I've not been sold on the criticality of adding content negotiation of
this form. You say you're interested in the privacy benefits, but the
draft doesn't state what those are expected to be, or what they're
being compared to. I assume they're being compared to 0.5RTT data. If
that's true, then sure, I can see the privacy benefits. However,
that's not the status quo, and so not necessarily a meaningful
comparison point.

The document notes a single rationale:

>   One of the properties of the
>   mechanism as defined by both of those protocols is that the parties
>   start out without having access to the entirety of the peer's
>   settings.  This means that they have to initially operate using the
>   default settings, and after receiving the SETTINGS frame, they have
>   to find a way to transition from the default to the exchanged
>   settings.

I agree that this statement is an accurate representation of the state
of things today. I also agree that having access to the settings
before application traffic is negotiated will enable some use-cases
that are otherwise tricky. But this is still not a concrete problem
statement, merely a statement of hypothetical utility.

> > My biggest concerns are around the need to tightly couple the TLS and
>
> > application layer stacks.
>
>
> I agree this adds a non-I/O TLS interaction, but adding interactions isn’t new. Many HTTP mechanisms touch TLS:
>
> RFC8473 uses TLS exporters.
> RFC5929 specifies various TLS channel bindings interfaces for authentication protocols.
> RFC8470 integrates with the 0-RTT/1-RTT transition point.
> ALPN itself uses TLS to select variations on HTTP.
> Section 9.2.2 of RFC7540 specifies cipher suites for HTTP/2.
> HTTP/2 cross-name pooling and HTTP’s general notion of authority are tied to the TLS certificate.
> Applications using client certificates care about the relation between TLS-level authentication and HTTP messages. The web even has a notion of “uncredentialed” HTTP fetches which shouldn’t send client certificates.
> Secondary certificates use TLS exported authenticators.
>
> Systems and thus their problems span components. The question is how best to split a solution across those components. The aim with ALPS is to minimize coupling while still getting settings for the first client write. We can build something piecemeal with half-RTT, ticket state, and early data callbacks. Or we can abstract a notion of “protocol settings”, configured and surfaced at well-defined points. I prefer the latter.

Systems do span components, but reducing coupling between those
systems is good. I agree that glomming things together out of an
arbitrary collection of poorly supported protocol components is not a
better solution than having a single extension point. I am pressing
back on the idea that this problem requires coupling these systems at
all. Well-designed, simple, extensible coupling is better than poorly
designed coupling, but worse than no coupling at all.

> As to the complexity, I think you may be overestimating it. It sounds like your model has three components: TLS, HTTP/2, and some ALPN dispatcher. And your concern is complexity in HTTP/2. Is that right? ALPS should slot next to ALPN processing at the same points. For example:
>
> The dispatcher already must know which ALPN protocols are supported and how to instantiate them.
> Extend it so protocols can optionally be ALPS-aware. An ALPS-aware protocol has a settings parameter in the instantiation function. It also configures settings to send. This all happens at the same time as existing ALPN setup.
> The dispatcher runs the TLS handshake and gets an ALPN protocol as before, plus now an ALPS value.
> The dispatcher instantiates the protocol as before, but if ALPS was negotiated, also passes a byte string to the ALPS-aware handler. Note the extension ensures this can only happen if the protocol was configured as ALPS-aware above.
>
> The protocol acts accordingly. If ALPS was negotiated, HTTP/2 would apply the received settings to the initial peer state. It also knows the initial local state is different and can skip sending some values. This is added logic to HTTP/2, but I think it’s fairly minimal. (And we can certainly figure out the exact details that would work best.) It even has precedent in the HTTP Upgrade path for “http” URLs, so it's not even really new. Also note that all this happens before any of the usual application I/O. (I wasn't sure what you meant by "timing issues". Could you elaborate? I read it to mean where the integration points were, so hopefully the example above helps clarify. Also note that all of the logic above is synchronous. We don't need new points in state machines to wait for data.)

The above is, in various subtle ways, not going to match what I have
to deal with. That's not the end of the world though: we shouldn't
critique this general proposal based on one specific implementation.

The timing issues here are around your "note that this happens before
any of the usual application I/O". This is not a trivial invariant to
enforce, and many stacks haven't had to bother. Highly integrated
stacks such as those found in major user agents and standard HTTP
servers tend to have this ironed out, but frameworks that support
arbitrary configuration have extra work to do here.

Nonetheless, I agree that the complexity here is not unmanageable.

---

From: Cory Benfield <[email-masked]>
Date: Mon, 1 Feb 2021 13:49:53 +0000

Oh, and I should say this out loud: my attitude to ALPS has softened
in the past two months or so. I definitely don't want my comments to
be perceived as being in opposition to the adoption of new work by
this WG: I just want to flesh out exactly what problems we're trying
to solve, so that we can accurately assess whether ALPS is the right
solution for them.

ALPS is a good solution to some real problems. I want to make sure I
understand what problems it's solving in H2, so I can try to judge
whether I think it's a good solution for _those_ problems.

---

From: David Benjamin <[email-masked]>
Date: Mon, 1 Feb 2021 14:49:38 -0500

On Mon, Feb 1, 2021 at 8:46 AM Cory Benfield <[email-masked]> wrote:

> > To clarify, are you unconvinced that ALPS is easier than leaving H2
> alone, or that ALPS is easier than solving this problem with half-RTT? The
> document’s aim is the latter. Your comment in Martin’s thread reads to me
> like you agree with this. Am I interpreting that correctly? (I think
> draft-thomson-httpbis-h2-0rtt roughly corresponds to Section 2.3 of my
> document. Something like it would be necessary, but not sufficient, to
> solve this with half-RTT.)
> >
> >
> > As to leaving H2 alone, doing nothing is indeed generally easier than
> doing something. But this is perhaps not a useful criteria. :-) The
> question is what’s the benefit of solving the problem. My interest is in
> the privacy benefits of rethinking content negotiation. Victor has use
> cases around WebTransport. The document cites some other uses.
>

Ah, sorry, I think I was unclear here. The problem with trying to divide
things up into abstractions is that it's very easy to mix up talking about
the abstractions on their own vs. the broader context. :-) Let me try that
again:

ALPS aims to fix the ordering of H[23] SETTINGS relative to HTTP requests.
In evaluating this, I think it's worth separating out:
1. What are the benefits to solving this problem, however we solve it?
2. Assuming we want to solve this problem, what is the best way to do it?
ALPS? Half-RTT? Something else?

And then the question is whether (1) justifies the best solution we can
find for (2). The alps-half-rtt document mostly discussed (2), while my
reference to privacy properties was about (1). (I don't think ALPS and
half-RTT have immediate differences in privacy properties. Though I think
there may be some indirect ones w.r.t. how robustly we can communicate the
authenticated vs. unauthenticated distinction across TLS and the
application protocol.)

To more concretely talking about (1):

My interest is in Client Hint Reliability. We're looking to shift some
information away from being always sent in client requests, notably in the
User-Agent header, to only being sent when requested. That'll help with
detecting and mitigating fingerprinting. Something like ALPS will help
smooth over the perf costs of this.
https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability-02
https://github.com/bslassey/privacy-budget

Victor touched on some other use cases here. I'll let him elaborate on what
else he has in mind.
https://lists.w3.org/Archives/Public/ietf-http-wg/2020JulSep/0003.html

Finally, this idea originally came up with QUIC's integration between
SETTINGS and NewSessionTicket (roughly draft-thomson-httpbis-h2-0rtt, plus
some additional QUIC-specific ordering headers). We largely resolved those
but, IMO, unsatisfyingly. (It requires non-trivial h3/TLS integration, both
in 0-RTT acceptance criteria and when to process NewSessionTickets.) There
was some discussion about an alternate ALPS-looking approach (only in the
server-to-client direction), but the WG wanted it to work in both
directions, so... here we are. :-)
https://github.com/quicwg/base-drafts/issues/3086#issuecomment-543373506

> > Systems and thus their problems span components. The question is how
> best to split a solution across those components. The aim with ALPS is to
> minimize coupling while still getting settings for the first client write.
> We can build something piecemeal with half-RTT, ticket state, and early
> data callbacks. Or we can abstract a notion of “protocol settings”,
> configured and surfaced at well-defined points. I prefer the latter.
>

I certainly agree that, if we can keep the solution in one component,
that'll be preferable! I don't see a way to do that here. At the end of the
day, the TLS 1.3 handshake fully completes on the client before the server.
One way or another, if we want to get server data to the client without
adding a roundtrip to the protocol, it needs to be delivered while the
handshake is in progress. 0.5-RTT and ALPS are, ultimately, vehicles for
doing that. Sometimes we can play clever tricks by pretending the handshake
completed early, but since this early point has visibly different
connection and security properties, that doesn't seem a great option here.
But perhaps I'm missing something?

> > As to the complexity, I think you may be overestimating it. It sounds
> like your model has three components: TLS, HTTP/2, and some ALPN
> dispatcher. And your concern is complexity in HTTP/2. Is that right? ALPS
> should slot next to ALPN processing at the same points. For example:
> >
> > Extend it so protocols can optionally be ALPS-aware. An ALPS-aware
> protocol has a settings parameter in the instantiation function. It also
> configures settings to send. This all happens at the same time as existing
> ALPN setup.
> > The dispatcher instantiates the protocol as before, but if ALPS was
> negotiated, also passes a byte string to the ALPS-aware handler. Note the
> extension ensures this can only happen if the protocol was configured as
> ALPS-aware above.
> >
> > The protocol acts accordingly. If ALPS was negotiated, HTTP/2 would
> apply the received settings to the initial peer state. It also knows the
> initial local state is different and can skip sending some values. This is
> added logic to HTTP/2, but I think it’s fairly minimal. (And we can
> certainly figure out the exact details that would work best.) It even has
> precedent in the HTTP Upgrade path for “http” URLs, so it's not even really
> new. Also note that all this happens before any of the usual application
> I/O. (I wasn't sure what you meant by "timing issues". Could you elaborate?
> I read it to mean where the integration points were, so hopefully the
> example above helps clarify. Also note that all of the logic above is
> synchronous. We don't need new points in state machines to wait for data.)
>

Ah, interesting. I'm happy to talk about the details of your
implementation, if you'd like. Maybe out of band if it's too focused on a
single implementation for here? (I find data points on TLS-based
applications valuable. It helps inform my intuition on what shapes of APIs
work well.)

David

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 2 Feb 2021 17:40:01 -0500

The problems I personally have in mind (HTTP/3 datagrams, as used in MASQUE
and WebTransport) are more relevant to HTTP/3 than /2, that said some of
them do have HTTP/2 counterparts (WebTransport over HTTP/2, header
compression static dictionary negotiation).

On Mon, Feb 1, 2021 at 8:50 AM Cory Benfield <[email-masked]> wrote:

> > > Thanks all for the feedback. I’ve tried to address it below, but
> there's a lot of text, so please let me know if I’ve missed or
> misunderstood any of your points.
> > >
> > >
> > > Cory commented on SETTINGS_[HQ]PACK_ENABLE_STATIC_TABLES in
> draft-vvv-httpbis-alps-00. I agree that is odd. We’ve uploaded a draft-01
> that drops it.
> > >
> > >
> > > Cory also wrote:
> > >
> > > I agree this adds a non-I/O TLS interaction, but adding interactions
> isn’t new. Many HTTP mechanisms touch TLS:
> > >
> > > Applications using client certificates care about the relation between
> TLS-level authentication and HTTP messages. The web even has a notion of
> “uncredentialed” HTTP fetches which shouldn’t send client certificates.

---

From: Cory Benfield <[email-masked]>
Date: Wed, 3 Feb 2021 16:32:37 +0000

On Mon, 1 Feb 2021 at 19:49, David Benjamin <[email-masked]> wrote:
> Ah, sorry, I think I was unclear here. The problem with trying to divide things up into abstractions is that it's very easy to mix up talking about the abstractions on their own vs. the broader context. :-) Let me try that again:
>
> ALPS aims to fix the ordering of H[23] SETTINGS relative to HTTP requests. In evaluating this, I think it's worth separating out:
> 2. Assuming we want to solve this problem, what is the best way to do it? ALPS? Half-RTT? Something else?
>
> And then the question is whether (1) justifies the best solution we can find for (2). The alps-half-rtt document mostly discussed (2), while my reference to privacy properties was about (1). (I don't think ALPS and half-RTT have immediate differences in privacy properties. Though I think there may be some indirect ones w.r.t. how robustly we can communicate the authenticated vs. unauthenticated distinction across TLS and the application protocol.)
>
> My interest is in Client Hint Reliability. We're looking to shift some information away from being always sent in client requests, notably in the User-Agent header, to only being sent when requested. That'll help with detecting and mitigating fingerprinting. Something like ALPS will help smooth over the perf costs of this.
> Victor touched on some other use cases here. I'll let him elaborate on what else he has in mind.
> Finally, this idea originally came up with QUIC's integration between SETTINGS and NewSessionTicket (roughly draft-thomson-httpbis-h2-0rtt, plus some additional QUIC-specific ordering headers). We largely resolved those but, IMO, unsatisfyingly. (It requires non-trivial h3/TLS integration, both in 0-RTT acceptance criteria and when to process NewSessionTickets.) There was some discussion about an alternate ALPS-looking approach (only in the server-to-client direction), but the WG wanted it to work in both directions, so... here we are. :-)
> I certainly agree that, if we can keep the solution in one component, that'll be preferable! I don't see a way to do that here. At the end of the day, the TLS 1.3 handshake fully completes on the client before the server. One way or another, if we want to get server data to the client without adding a roundtrip to the protocol, it needs to be delivered while the handshake is in progress. 0.5-RTT and ALPS are, ultimately, vehicles for doing that. Sometimes we can play clever tricks by pretending the handshake completed early, but since this early point has visibly different connection and security properties, that doesn't seem a great option here. But perhaps I'm missing something?

I think this comment here is the most salient one in the thread and
gets to the crux of the issue. If you don't mind, I'd like to echo
back to you my understanding of the common thread in the issues you're
seeing (both in H2 and H3) and then frame the discussion as I see it.
Please correct me if I've misunderstood.

Both yourself and Victor are fundamentally dealing with the problem
that you want to remove an RTT. In Victor's case this is largely
coming up because he has extensions that need to be negotiated, and in
HTTP/2 that negotiation necessarily happens after the packet exchange
for the TLS handshake. In your case, this is coming up because you
want the server to be able to express its preferred client hints,
which again cannot happen until after the client Finished has been
received (forcing a 1RTT delay).

If my understanding is right, I'd like to ask a question. What's the
reason to specifically codify a settings-based exchange, instead of
providing a generalised extension to TLS to allow this kind of
handshake nesting? It seems that the problem is general-case, and it
would be nice if we didn't have to just have a single big lump called
"settings". As a silly but illuminating example, TLS-in-TLS would not
benefit from ALPS.

> Ah, interesting. I'm happy to talk about the details of your implementation, if you'd like. Maybe out of band if it's too focused on a single implementation for here? (I find data points on TLS-based applications valuable. It helps inform my intuition on what shapes of APIs work well.)

If you're curious we can follow up off-thread and I can walk you
through the abstractions as they exist.