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

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 <cory@lukasa.co.uk> wrote:

> 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.
>
> On Mon, 1 Feb 2021 at 13:46, Cory Benfield <cory@lukasa.co.uk> wrote:
> >
> > On Fri, 29 Jan 2021 at 23:38, David Benjamin <davidben@chromium.org>
> 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.
>