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

[Cory Benfield <[e-mail]>]

On Fri, 29 Jan 2021 at 23:38, David Benjamin <[e-mail]> 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.