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

[Cory Benfield <[e-mail]>]

On Mon, 1 Feb 2021 at 19:49, David Benjamin <[e-mail]> wrote:
>
> On Mon, Feb 1, 2021 at 8:46 AM Cory Benfield <[e-mail]> wrote:
>>
>> On Fri, 29 Jan 2021 at 23:38, David Benjamin <[e-mail]> 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?

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.


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

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