Re: [TLS] ALPS and TLS 1.3 half-RTT data

[Cory Benfield <[e-mail]>]

On Thu, 3 Dec 2020 at 21:56, David Benjamin <[e-mail]> wrote:
>
> Hi TLS and HTTP friends,
>
> At the last HTTPWG interim, there was a question of why one would want something like ALPS (draft-vvv-tls-alps) for HTTP SETTINGS (draft-vvv-httpbis-alps) over TLS 1.3 half-RTT data. I know we've also had some discussion on this topic in the TLSWG as well. At the HTTP meeting, folks suggested writing up what a half-RTT-based mechanism might look like, so I put together an I-D below. I hope it helps clarify some of our thinking.
>
> (The I-D is not meant for adoption or publication or anything. I figured an I-D was probably the most familiar format for folks.)
>
> David

Thanks for producing this document David: I think I was one of the
folks who pushed for clarification in this area.

I think the document does a good job laying out the difficulties with
half-RTT data, but it didn't convince me that ALPS is easier for H2.

My biggest concerns are around the need to tightly couple the TLS and
application layer stacks. ALPN has been reasonably straightforward to
handle, being essentially a static byte sequence vended by the
application layer protocol. QUIC transport parameters are already
harder, but for things like H2 the state machines have to be
complicated by the addition of an essentially parallel I/O path. This
is because, unlike QUIC, H2 does not (and cannot) spec the requirement
for supporting the ALPS extension so the state machines need to
tolerate the possibility that they will supply the SETTINGS as
ALPS-data but then need to redeliver it in-band, which is fairly
unpleasant (doubly so for servers that may want to use multiple TLS
stacks, which now have to mitigate timing issues).

I think if ALPS were restricted to protocols that could mandate its
support then ALPS seems great. For H2 this seems unlikely to be
deployed in the long-tail which limits its usefulness, and tbh I think
brings more complexity than it's worth.