Re: [TLS] Application-Layer Protocol Settings

[David Benjamin <[e-mail]>]

Hi Ben,

(I’ve covered many of these points in my reply to Martin, so you may want
to read that first.)

Any solution here involves a TLS change, even for servers which currently
send half-RTT settings. See my reply to Martin for why. The question then
is which is more complex. As a TLS implementor, ALPS would be a very
straightforward extension to implement, while the work involved to make
half-RTT SETTINGS work would be a mess.

Transparently sending a fixed buffer of half-RTT data was indeed something
we’d thought about and rejected. In some circumstances, it may cause
deadlocks with TCP
<https://mailarchive.ietf.org/arch/msg/tls/hymweZ66b2C8nnYyXF8cwj7qopc/>.
And we still need an indicator for the client to safely wait for it. I/O
patterns are part of the protocol.

It’s also not the case that non-uniform backends must disable 0-RTT. That
is what 0-RTT rejection logic is for. Non-uniform deployments may get less
0-RTT than a uniform deployment, but it won’t break things. This is already
the case (ALPN must match) and unavoidable with any predictive mechanism
like 0-RTT.

Finally, you’re right to think about the coupling between TLS and HTTP for
0-RTT, but I believe you have the conclusion backwards. The TLS stack must
be deeply aware of what is stored in the TLS session, so the server can
reject 0-RTT when the remembered values are incompatible with its current
configuration (see HTTP/3
<https://quicwg.org/base-drafts/draft-ietf-quic-http.html#section-7.2.4.2-7>).
Otherwise the client will act thinking the server supports some extension
when, in reality, it does not. (Perhaps the server had to roll the feature
back.)

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. Tighter coupling could be aware that, e.g.,
SETTINGS_MAX_CONCURRENT_STREAMS = 500 is compatible with 1000 but not 100.
The draft starts with the simplest option, given settings don’t change
much. It’s already the case that configuration changes, like cipher
preferences, may reject 0-RTT. (Note settings which do change can still be
sent in application data. ALPS’s purpose is to solve the reliable
negotiation problem, and any changing setting won’t be reliable in 0-RTT
anyway. Moving them out of ALPS entirely seems fairly clean.)

David

On Mon, Jul 6, 2020 at 10:23 PM Ben Schwartz <bemasc=
[e-mail]> wrote:

> 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/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
>>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>