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

On Mon, Feb 1, 2021 at 8:46 AM Cory Benfield <cory@lukasa.co.uk> wrote:

> On Fri, 29 Jan 2021 at 23:38, David Benjamin <davidben@chromium.org>
> 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.
>
> 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.
>

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.
>
> 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.
>

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:
> >
> > 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.
>

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