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

[Cory Benfield <[e-mail]>]

On Wed, 16 Dec 2020 at 10:16, Cory Benfield <[e-mail]> wrote:
>
> On Fri, 11 Dec 2020 at 03:44, Victor Vasiliev <[e-mail]> wrote:
> >
> > 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.
>
> The distinction here is that a HTTP/2 stack needs to know what the
> peer sent for ALPS, which it never did for ALPN. That is, it was
> possible to compose TLS and HTTP/2 entirely independently: the TLS
> implementation accepted the static byte string from HTTP/2, and if the
> ALPN it negotiated matched that string it had successfully negotiated
> HTTP/2. I agree that applications needed to know what the ALPN
> negotiation was, but HTTP/2 did not. You can observe this in OSS
> stacks in the wild, where the HTTP/2 stack never sees the result of
> the ALPN negotiation.
>
> ALPS affects the HTTP/2 wire protocol: it is mandatory that the HTTP/2
> stack behind the TLS implementation be actively told what the peer
> presented in ALPS. This was not required with ALPN (H2 could assume it
> was being driven based on successful ALPN negotiation of its H2 ALPN
> token). While this is not novel for QUIC (see also Transport
> Parameters), it is absolutely novel for H2.
>
> > 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.
>
> The two aren't the same, and the ALPS draft has so far skated around
> this problem by not specifying how ALPS would actually work with
> HTTP/2. In particular, ALPS must interact with the § 3.5 connection
> preface in some way. The draft doesn't say how this would work, but
> the logical design is that if ALPS is successfully used the connection
> preface will be different (it won't bother to include SETTINGS
> frames). This cannot help but require tighter coupling between H2 and
> TLS, as the H2 stack must now be fed the ALPS data sent by the peer
> before it can parse any bytes from that peer. This is simply not a
> limitation we have today.

David Benjamin kindly followed-up with me off-list to note that I
missed an ALPS draft that does express how ALPS maps into HTTP/2.
Happily, my guess about how ALPS would map into HTTP/2 matches the
document exactly, so the remainder of my criticism still applies.

While I'm here though, I'd like to add an additional point regarding
draft-vvv-httpbis-alps-00, which is that section 4 should be revised.
Specifically, section 4 mandates that any HTTP/2 endpoint that
supports ALPS MUST support SETTINGS_HPACK_ENABLE_STATIC_TABLES. The
word "support" is unclear here: do I merely have to know what the
setting is, or do I have to actually support the functionality? I can
only presume the latter, given that ALPS does not support any concept
of negotiation.

I ask because I think coupling these two features together is
unreasonable, and places an unnecessary burden on implementers. There
is also no reason to couple them together. This setting should be a
separate draft, and should require an appropriate "I support you
setting this to 0, but will not be setting it to 0 myself." setting
value. This allows peers that actually support this functionality to
indicate support for it, without requiring that it be implemented by
anyone adopting ALPS.

> It is also different from making the existing logic conditional, as
> presumably we wouldn't bother with SETTINGS ACKs for ALPS settings.
> This is because a) the whole point of ALPS is that those settings are
> well-ordered w.r.t. the rest of the protocol, obviating the need for
> the ACK at all, and b) it would violate existing stack's assumptions
> that SETTINGS ACKs can only be received in response to SETTINGS
> frames. This requires a different path for the ALPS settings.
>
> I want to stress: I don't think ALPS is a bad idea, I think it's a
> good one! It clearly brings benefits for protocols that can require
> its presence. If we want to mint a new ALPN token for HTTP/2 that also
> mandates ALPS support I'm open to that, but frankly without it I don't
> see that ALPS helps us much for HTTP/2.
>
> >
> > On Tue, Dec 8, 2020 at 3:48 AM Cory Benfield <[e-mail]> wrote:
> >>
> >> 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.
> >>
> >> _______________________________________________
> >> TLS mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tls