On Wed, 16 Dec 2020 at 10:16, Cory Benfield <c...@lukasa.co.uk> wrote: > > On Fri, 11 Dec 2020 at 03:44, Victor Vasiliev <vasi...@google.com> 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 <c...@lukasa.co.uk> wrote: > >> > >> On Thu, 3 Dec 2020 at 21:56, David Benjamin <david...@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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
