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

On Fri, 11 Dec 2020 at 03:44, Victor Vasiliev <vasilvv@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.

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

Received on Wednesday, 16 December 2020 10:17:01 UTC