Re: [TLS] Application-Layer Protocol Settings

[Victor Vasiliev <[e-mail]>]

On Tue, Jul 7, 2020 at 1:10 AM Martin Thomson <[e-mail]> 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.
>

It's both about solving the "lack of 0.5-RTT send capability" problem, and
about making the client aware that it will in fact get the settings in
0.5-RTT without having to risk waiting for an entire RTT.  I don't think
you can avoid putting a "I will correctly send and receive 0.5-RTT data"
signal into any location other than the TLS handshake, so this is less of a
question of *should*, and more of *how*.

For what it's worth, I don't think we should define a new ALPN token for
that; using ALPN tokens for flags will eventually lead to combinatorial
explosion (e.g. "if we define h2_half_rtt, we have to define h2c_half_rtt",
etc), and can also lead to some really unpleasant situations with Alt-Svc.

Also, as far as I am aware, SETTINGS are currently not carried over for
HTTP/2 0-RTT in any form, meaning that it's currently impossible to, for
example, send a WebSocket CONNECT request in HTTP/2 0-RTT.  The proposed
draft fixes that.


> 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?"
>

This probably works for 1-RTT, but I am not quite sure it would work with
0-RTT as currently defined in HTTP/3.


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

HTTP/3 approach to 0-RTT settings is based around the idea that things work
just fine with default settings (which is true if you don't have extensions
you care about), whereas ALPS aims to provide "actual settings are always
there" guarantee.  If you define extensions that require blocking on
settings, then not remembering settings makes 0-RTT useless anyways, so
this is kind of moot.  That said, we could add an "upgrade to compatible
settings" mechanism similar to QUIC if people believe it's useful.

Also, from what I recall, the approach we chose for HTTP/3 was partially
motivated by the ordering ambiguity between SETTINGS and NewSessionTicket,
which the proposed draft removes.


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