Re: [TLS] Application-Layer Protocol Settings

[Ben Schwartz <[e-mail]>]

Thanks for this draft.  I believe this is an important problem for HTTP
extensibility, and I'm glad to see work on a solution.

It occurs to me that this solution requires pretty tight integration
between the TLS termination and the HTTP backend.  Some TLS load balancers
already support ALPN, but they would have to be extended to support ALPS,
and I would worry about the potential for skew between the TLS terminator's
claimed settings and the backend's actual settings.

The draft says
   1.  While the server is technically capable of sending configuration
       to the peer as soon as it sends its Finished message, most TLS
       implementations do not allow any application data to be sent
       until the Finished message is received from the client.

Fixing this might require a change to some TLS implementations, but the
change to implement ALPS also seems significant.

The proposed 0-RTT interaction also seems like it would create a
significant risk of skew when a load balancer is in use, if the backend
settings can change.  Deployments that can't guarantee uniform backends
would have to disable 0-RTT (an unfortunate sacrifice for a feature that
saves 1 RTT!).

For load balancers, or any other situation where TLS and HTTP are loosely
coupled, sending SETTINGS at 0.5-RTT would seem like a much simpler
solution.  I know the draft mentions a few cases where this doesn't work
well, but perhaps there's a middle ground of some sort.  For example:

* If supporting generic 0.5-RTT forwarding is hard, TLS server
implementations could offer a configuration to send an arbitrary fixed
buffer at 0.5-RTT (depending on ALPN).  No standards change is required.
* The application protocol (here HTTP) could indicate what state is
guaranteed to persist across session resumption.  Although the preserved
state here (SETTINGS) is ~static, in general this could include dynamic
session state too.  This would move the change to HTTP, instead of TLS.

On Mon, Jul 6, 2020 at 3:13 PM Victor Vasiliev <vasilvv=
[e-mail]> wrote:

> Hello TLS and HTTP working groups,
>
> (QUIC WG bcc'd as this has been discussed there before)
>
> Currently, we use SETTINGS frames as an extensibility mechanism in HTTP/2
> and HTTP/3.  The SETTINGS frame is sent at the very beginning of TLS
> application data; this approach, while simple, has some drawbacks.  The
> most notable one is that when SETTINGS are used to negotiate extensions,
> there is an entire round-trip where the client can send requests, but
> doesn't know yet about any server extensions, thus making any
> extension-dependant requests take an extra RTT.
>
> The proposed solution to this problem is to move HTTP SETTINGS frame into
> the TLS handshake.  Here are some issues where this has been discussed
> before:
>
>    - https://github.com/quicwg/base-drafts/issues/3086
>    - https://github.com/quicwg/base-drafts/issues/3622
>    - https://github.com/WICG/client-hints-infrastructure/pull/30
>
> I wrote up a draft for the TLS extension that would solve this problem:
> https://tools.ietf.org/html/draft-vvv-tls-alps-00
>
> I also wrote up a draft that explains how to use that extension with HTTP,
> and defines some settings (the ones discussed here
> <https://github.com/quicwg/base-drafts/issues/3622>) that would not be
> possible without it: https://tools.ietf.org/html/draft-vvv-httpbis-alps-00
>
> I would appreciate feedback on those drafts.
>
> Thanks,
>   Victor.
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>