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 <c...@lukasa.co.uk> wrote: > > On Fri, 29 Jan 2021 at 23:38, David Benjamin <david...@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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
