Re: [TLS] Application-Layer Protocol Settings

On Tue, Jul 7, 2020 at 4:38 PM Ben Schwartz <bemasc@google.com> wrote:

>
> On Tue, Jul 7, 2020 at 3:14 PM David Benjamin <davidben@chromium.org>
> 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.
>

That doesn't suffice. Please see my reply to Martin. This would be one
possible spelling of the indicator, but it would not provide the other
components necessary for half-RTT data to work.


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

HTTP/3 0-RTT *already* requires such an interaction. In fact, it requires
an even more complex version than ALPS. The link was lost in the quoted
reply, so I'll include it again:
https://quicwg.org/base-drafts/draft-ietf-quic-http.html#section-7.2.4.2-7

This is fundamentally unavoidable if you want 0-RTT to be able to use
negotiated parameters. Any negotiated parameter available to 0-RTT *must* be
available predictively. Because it is predictive, mispredictions may occur.

RFC8470 likewise contains recommendations which also require more than a
"decrypt and forward" approach.


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

It's right here: https://tools.ietf.org/html/draft-vvv-tls-alps-00#section-3

>   For application protocols that support 0-RTT data, both the client
>   and the server have to remember the settings provided by the both
>   sides during the original connection.  If the client sends 0-RTT data
>   and the server accepts it, the ALPS values SHALL be the same values
>   as were during the original connection.  In all other cases
>   (including session resumption that does not result in server
>   accepting early data), new ALPS values SHALL be negotiated.
>
>   If the client wishes to send different client settings for the 0-RTT
>   session, it MUST NOT offer 0-RTT.  Conversely, if the server would
>   send different server settings, it MUST reject 0-RTT.  Note that the
>   ALPN itself is similarly required to match the one in the original
>   connection, thus the settings only need to be remembered or checked
>   for a single application protocol.


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

I don't think this follows. ALPS and half-RTT data happen at the same
round-trip. If the frontend is able to forward half-RTT data, it has
clearly decided on which backend to use by the time it's assembling the
ServerHello flight. It can as easily pick a backend-specific ALPS value as
it can pick backend-specific half-RTT data.

Beyond that, it's a question of what exactly your frontend/backend split
looks like. I gather you're worried about a deployment scenario where your
frontend is a TLS terminator, which has a boring pipe to the HTTP backend,
without any out-of-band signaling. (As opposed to having an HTTP frontend.)
In that case, the argument is that, since half-RTT data is just bytes, that
can be transparently forwarded over the pipe, whereas an ALPS signal
wouldn't. Is that right?

It's unlikely half-RTT data would work for that scenario. The frontend most
likely waits for the handshake to actually finish, before enabling the
pipe. Indeed, the security properties of the half-RTT point are kind of
subtle (particularly with client certs). Forwarding data then without
appropriate signaling is dangerous.

Such a frontend/backend split would also likely be unable to manage the
recommendations in RFC8470, the remembered settings vs. 0-RTT interactions,
the guarantee of half-RTT data being sent early enough, or the delimiting
information necessary to make a half-RTT settings work. For that matter, it
already needs some out-of-band signaling to communicate the ALPN protocol.

ALPS probably even helps this kind of deployment, by at least making it
possible to statically configure the settings. Static configuration risks
the footguns you mention below, but when all you've got is a boring pipe,
there aren't many options.

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

Again, this depends on where your frontend/backend split is, and what is
the communication between them. Note also that this hypothetical deployment
model already has a similar footgun around ALPN.

David