Re: [TLS] Application-Layer Protocol Settings

Hi Martin,

You’re right that this is closely related to half-RTT data. However, I
don’t think this is a no-op for HTTP/2.

I’m not aware of HTTP/2 clients that wait for the SETTINGS frame today.
Doing so costs a round-trip with servers that don’t send SETTINGS in
half-RTT, and there's no indicator for whether the server will send it.
I’ll see about testing some sites here and will report back, but I expect
most do not. We (correctly) designed TLS 1.3 as a drop-in replacement for
TLS 1.2, which means that we don't get to key new I/O patterns on it.
Half-RTT data is a very weird state and wouldn’t get used by default. This
is the problem with “no standards change is required” style of thinking
around simply changing I/O patterns. A protocol is more than its wire
image. Changing the I/O patterns is a protocol change.

This means we cannot get efficient and reliable feature negotiation today.
Moreover, HTTP/2 servers today may send ServerHello..Finished without
application data in their first flight, so we need *some* change to the TLS
flight, be it ALPS or just some indicator.

Let’s look at what it’d take to make half-RTT SETTINGS work. We need some
“I will send half-RTT data, so you can safely wait for it” indicator. Then
the client needs to know when it is done waiting. We could say it’s one
SETTINGS frame, but that only allows integer values. (Related:
EXTENDED_SETTINGS
<https://tools.ietf.org/id/draft-bishop-httpbis-extended-settings-01.html>
and discussion
<https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0127.html>.)
Those currently need separate frames, and one cannot wait for the absence
of a frame. Maybe we need an HTTP-level
SETTINGS_WILL_SEND_HALF_RTT_XYZ_FRAME indicator to keep the delimiter in
HTTP, or a TLS-level “end of half-RTT data” delimiter. (Now consider how
that works in QUIC...)

Next we need to tackle 0-RTT. Waiting for half-RTT data costs a round-trip
in 0-RTT, so we need something to persist across the session, with
semantics around mismatch and whatnot. (Another TLS-visible change.)
Anything persisted in the session must have bounded size, and be delivered
in something ordered with NewSessionTicket.

If we place those bytes inside the handshake, we’ve reinvented ALPS. If we
place them outside, the NewSessionTicket ordering becomes complex,
especially in QUIC
<https://github.com/quicwg/base-drafts/issues/2945#issuecomment-519338186>.
To your question about the server repeating its configuration vs. the
client remembering it, I believe the issue was exactly that ordering
mishap. ALPS avoids this because EncryptedExtensions and NewSessionTicket
are ordered.

On top of this, the half-RTT point in a non-0-RTT connection is a weird
state. Not all connection properties (e.g. client certs) have been
established yet, and writes out of turn are tricky. This message
<https://mailarchive.ietf.org/arch/msg/tls/hymweZ66b2C8nnYyXF8cwj7qopc/>
discusses
some of the challenges here. I would argue something like ALPS is the
settings design we should have had all along.

David

On Tue, Jul 7, 2020 at 1:10 AM Martin Thomson <mt@lowentropy.net> wrote:

> Hi Victor,
>
> For HTTP/2, this is essentially a noop, as endpoints are required to send
> SETTINGS immediately.  Whether these bytes appear before Finished or not
> only affects endpoints that aren't inclined to wait for SETTINGS.  This is
> somewhat complicated by the way that TLS 1.2 and TLS 1.3 differ, but if we
> assume TLS 1.3 here, any uncertainty is easily avoided.
>
> The main justification here appears to be based on the lack of 0.5-RTT
> send capability at some servers.  I don't know how to assess whether the
> cost of greater integration with the TLS stack is preferable to fixing the
> 0.5-RTT send problem.
>
> For HTTP/3, this has some incremental effect beyond that.  In effect, this
> deliberately introduces head-of-line blocking for settings.  You can
> already do that in HTTP/3 if you are not prepared to deal with settings
> being in an ambiguous state.  There's a little more determinism here in
> terms of where you look for the data that unblocks progress, but with
> retransmissions, this is not a difference worth worrying about.
>
> What this head-of-line blocking might allow is the development of new
> extensions that are unable to deal with uncertainty regarding SETTINGS.
> But isn't it also possible to address that problem by saying "if you
> implement extension X, then you MUST NOT send requests prior to receiving
> SETTINGS?"
>
> In QUIC, we decided that having the server repeat its configuration after
> 0-RTT was preferable to remembering it.  This was after a non-trivial
> number of questions about that part of the specification.  You seem to have
> taken the opposite approach.  Is that deliberate?  If so, why?
>
> On Tue, Jul 7, 2020, at 05:12, Victor Vasiliev 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
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>