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

Hi Cory,

I am not sure there is a big difference between ALPN and ALPS in that
regard.  ALPS is (or at least can be implemented as) "essentially a static
byte sequence vended by the application layer protocol".  Furthermore,
applications already have to vary their payloads dramatically depending on
signals from the TLS stack whenever they implement ALPN (by choosing, e.g.,
HTTP/1.1 vs HTTP/2).  From that standpoint, it seems natural for ALPS
handling to happen at the same or similar I/O points as ALPN handling.

I am confused by the "fairly unpleasant" part; given that the existing
implementations already can change settings in-band, this sounds like it's
just a matter of making the existing logic conditional.

On Tue, Dec 8, 2020 at 3:48 AM Cory Benfield <cory@lukasa.co.uk> wrote:

> On Thu, 3 Dec 2020 at 21:56, David Benjamin <davidben@chromium.org> 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.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>