Re: [TLS] Application-Layer Protocol Settings

[Ben Schwartz <[e-mail]>]

On Tue, Jul 7, 2020 at 3:14 PM David Benjamin <[e-mail]> wrote:

> Any solution here involves a TLS change, even for servers which currently
> send half-RTT settings. ...
>

I think a new ALPN protocol ID
("h2-but-with-settings-from-the-server-asap-for-real") would suffice.

It’s also not the case that non-uniform backends must disable 0-RTT. That
> is what 0-RTT rejection logic is for. ...
>

I would be impressed if there is any TLS load balancer architecture that
supports 0-RTT rejection by the backend.  This would require an interesting
new metadata layer, quite different from the usual "decrypt and forward"
approach.  (Of course, I assume that most load balancers simply won't
implement 0-RTT at all.)

The simpler that TLS/HTTP interaction, the looser the coupling we can
> manage, and checking opaque bytes for equality is the simplest possible
> option here.
>

I'm not sure what equality check you're proposing; I don't see it in the
draft.  However, I agree with your conclusion: if the TLS server manages
the settings-state, it can easily invalidate resumption across a settings
change.

Ultimately, I think I'm saying something obvious: if the TLS server
represents multiple backends without distinction, it can't represent a
property that those backends do not share.  This is true of ALPN, and would
be true of ALPS too.  This is fine; the ALPS just has to represent the
intersection of backend capabilities.  All currently defined HTTP/2
Settings appear to support intersection in a reasonable way, although I'm
not sure this is guaranteed in general.  However, SETTINGS at 0.5-RTT would
not have this problem; heterogeneous backends could each report their own
SETTINGS.

This is not an unreasonable design choice given the other constraints
you've mentioned, but it is a limitation, and potentially a footgun (e.g.
if someone forgets to revert the ALPS config change before rolling back the
HTTP server config change).