Re: The qpack_static_table_version TLS extension (Draft version 02)

[Christian Huitema <[e-mail]>]

If we are discussing ALPS for QUIC, it might make sense to make it a 
feature of QUIC rather than a feature of TLS -- since the application 
layer runs on top of QUIC, not on top of TLS. Plus, there are periodic 
discussion of running QUIC with some kind of replacement for TLS. Moving 
the feature to the QUIC layer would make it impervious to that.

Also, it would be completely trivial to define ALPS as a negotiated QUIC 
parameter.

The main issue would be the interaction between ALPS negotiation and 
ALPN negotiation. Suppose that the client proposes ALPN={"h3", 
"hq-interop", "h4-07"}. Presumably, the three applications propsoed 
would have different set of settings. Should there be just one ALPS 
parameter, or three?

Lastly, the whole discussion reminds me of an interop issue that we 
found when testing web transport between Picoquic and Aoiquic. The 
Picoquic server was sending a canned set of H3 parameters that indicated 
support for H3 datagrams. But datagrams were not negotiated as the QUIC 
layer, and the Aoiquic implementation was complaining that proposing 
support for datagrams in H3/WT made no sense when datagrams were not 
available at the QUIC layer. That forced Picoquic to implement a dynamic 
"settings" frame, in which supported H3 features depended on negotiated 
QUIC features.

Bottom line: we have to rationalize the interaction between TLS, QUIC, 
ALPN and settings.

-- Christian Huitema

On 12/12/2023 2:29 PM, David Benjamin wrote:
> That is not the current ALPS design, but it certainly could be if that's
> the consensus. However, as I noticed, that means the TLS <-> HTTP API
> requires a callback, so I would caution against that design.
> 
> As Mike and I said, that property is not necessary for negotiation. As long
> as there is a well-defined function from the pair of SETTINGS frames to
> what happens next (e.g. pick the latest preferred common one, reserve a
> byte somewhere to specify it in the header frame, etc), you do not need one
> message to depend on the other. Though I'm still quite unconvinced that we
> actually want vendor-specific tables. The example you gave (UA strings and
> client hint analogs) are ones where vendor-specific static tables would
> *definitely* not work. The UA and UA-CH values change on every release of
> the browser, and it would be unreasonable to define a new static. The
> accept headers are a bit more static but still change whenever new content
> types are added, so a static table would once again be too static.
> 
> If there are no use cases for an explosion of vendor-specific tables, I
> think this problem is much better solved by simply defining "h2.x" ALPNs
> every now and then and refreshing the static table when we find we need it.
> 
>> (0-RTT might still have sharp edges.)
> 
> ALPS is defined to carry over on 0-RTT precisely for this reason. See the
> discussion about early data in
> https://www.ietf.org/archive/id/draft-davidben-tls-alps-half-rtt-00.html#
> 
> On Tue, Dec 12, 2023 at 5:04 PM Rory Hewitt <[e-mail]> wrote:
> 
>> Yeah, if ALPS 'can be used as a de facto negotiation protocol' then life
>> is much easier - although does the first settings frame there come from
>> client or server?
>>
>> In any event, as long as one of them is able to send a list of supported
>> variant/length combinations and the other can reply with their chosen one
>> from that supported list, then we're golden.
>>
>> On Tue, Dec 12, 2023 at 8:06 AM Mike Bishop <[e-mail]> wrote:
>>
>>> ALPS not being a negotiation mechanism comes from the HTTP/QUIC idea that
>>> settings are not responses to each other, but unilateral declarations about
>>> a client’s state. The protocol then needs to describe what is safe to send
>>> / how to interpret things being received based on what is seen in SETTINGS.
>>>
>>>
>>>
>>> A more complex approach might be to assume the peer will have seen the
>>> SETTINGS you sent as well and define an algorithm to “negotiate” by
>>> combining what was sent and what was received.  No HTTP extensions to date
>>> have gone this far, largely because guarantees about ordering get a bit
>>> squishy, especially in QUIC.  The key benefit of ALPS is a guarantee that
>>> both sides have seen and processed the settings by the time the TLS
>>> handshake completes, so you can rely on such an algorithm in 1-RTT data.
>>> (0-RTT might still have sharp edges.)
>>>
>>>
>>>
>>> *From:* Rory Hewitt <[e-mail]>
>>> *Sent:* Monday, November 27, 2023 8:49 PM
>>> *To:* David Benjamin <[e-mail]>
>>> *Cc:* HTTP Working Group <[e-mail]>
>>> *Subject:* Re: The qpack_static_table_version TLS extension (Draft
>>> version 02)
>>>
>>>
>>>
>>> Hey David,
>>>
>>>
>>>
>>> Focusing in on what is (IMO) the most important bit of your response:
>>>
>>>
>>>
>>> Right, I think that's the ALPN vs ALPS question. If we believe a mess of
>>> vendor-specific static tables is worthwhile, we should do this with as
>>> subfeature and do something like ALPS. If we don't believe this is that
>>> important, and that we can live with a single, infrequently-updated,
>>> universal static table, let's just define h2.1 and move on with life.
>>>
>>>
>>>
>>> Given that the dynamic mechanism already compresses repeat headers after
>>> the first utterance, and that h2 and h3 are quite good at connection reuse,
>>> I suspect the h2.1 path is just fine. Or are you seeing that people are
>>> trying to make vendor-specific static tables already? I've not heard of
>>> this happening.
>>>
>>>
>>>
>>> I haven't seen any evidence that any vendors are creating their own
>>> static tables. But if I were, let's say, Google (random example, I swear),
>>> I would note that Chrome appears to send a number of headers with every
>>> request for a web page, some of which are very big, and would therefore
>>> benefit significantly from being added to a static table, e.g.:
>>>
>>>
>>>
>>>
>>> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
>>>
>>> Sec-Ch-Ua: "Google Chrome";v="119", "Chromium";v="119",
>>> "Not?A_Brand";v="24"
>>> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
>>> (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36
>>>
>>>
>>>
>>> Leaving aside the discussion of if/when the User-Agent header will be
>>> frozen and what form it will take at that point, that's a lot of bytes
>>> (340-ish)! Using static table entries for name/value combos reduces that to
>>> about 12 bytes. Dynamic table Huffman coding compression doesn't even get
>>> close.
>>>
>>>
>>>
>>> So I can certainly see vendors seeing the benefit of being allowed to
>>> define small (possibly vendor-specific) tables as a noticeable benefit over
>>> and above the h2.1 path.
>>>
>>>
>>>
>>> If ALPS works as a negotiation mechanism, then coolio. I was mistakenly
>>> under the impression that it wouldn't.
>>>
>>>
>>>
>>> Rory
>>>
>>>
>>>
>>> On Mon, Nov 27, 2023 at 12:43 PM David Benjamin <[e-mail]>
>>> wrote:
>>>
>>> On Mon, Nov 27, 2023 at 3:21 PM Rory Hewitt <[e-mail]>
>>> wrote:
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Nov 27, 2023 at 10:57 AM David Benjamin <[e-mail]>
>>> wrote:
>>>
>>>> FWIW, I'm inclined to come out against the idea of using ALPS rather
>>> than a TLS extension, primarily because ALPS is specifically NOT designed
>>> to be a negotiation mechanism.
>>>
>>> I think this may be fixating too much on the name and missing what the
>>> extension actually does.
>>>
>>>
>>>
>>> As one of the folks involved in the original design, I think I can
>>> authoritatively say this is false. We named ALPS S for settings simply
>>> because "ALPS" is easy to pronounce, and because the corresponding message
>>> in h2 and h3 is called SETTINGS. It is absolutely designed to communicate
>>> application protocol capabilities and preferences... in other words,
>>> negotiation. Indeed we specifically had [HQ]PACK static tables in mind as a
>>> use case when designing this. See here:
>>>
>>>
>>> https://www.ietf.org/archive/id/draft-davidben-tls-alps-half-rtt-00.html#section-1-2
>>>
>>>
>>>
>>> Ah - I was indeed fixating on this (Section 3 - semantics):
>>>
>>> ALPS is _not_ a negotiation mechanism: there is no notion of rejecting peer's settings, and the settings are not responses to one another.
>>>
>>>
>>>
>>> Ah, forgot about that text. This document is old. :-) I believe this was
>>> just trying to capture that each side's blobs were expected to be
>>> configured mostly statically. See the immediately following text:
>>>
>>>
>>>
>>>> Nevertheless, it is possible for parties to coordinate behavior by, for
>>> instance, requiring a certain parameter to be present in both client and
>>> server settings. This makes ALPS mechanism similar to QUIC transport
>>> parameters [I-D.ietf-quic-transport] or HTTP/2 SETTINGS frame [RFC7540],
>>> but puts it in contrast to similar mechanisms in TLS.
>>>
>>>
>>>
>>> I.e., this was just trying to capture that this is akin to the QUIC and
>>> HTTP pattern, rather than the TLS pattern where one side's message is
>>> directly in response to the other. We didn't want to invent a whole new
>>> pattern and just try to patch up the issues with the existing one. (At the
>>> end of the day, you just need *something* to signal that the new thing
>>> is happening, and then the rest is just protocol engineering.)
>>>
>>>
>>>
>>> Though also I don't consider these details to be that fundamental. We
>>> probably could have allowed the client one to be in response to the server
>>> one, if people prefer that. It just would have encouraged a more complex,
>>> asymmetric callback API. Such a callback would be particularly challenging
>>> considering that your h2 logic may be far from your TLS terminator in some
>>> deployments. Thus it seemed cleanest to use static messages and have
>>> everything flow from there. (You just need *something* that consistently
>>> signals to both sides, at the right time, that the new thing is happening.)
>>>
>>>
>>>
>>>> Of course basic ALPN IS a negotiation mechanism (it's right there in
>>> the name!)
>>>
>>>
>>>
>>> I think this is further fixating on naming coincidences. The N in ALPN
>>> doesn't mean "Negotiation *within* an Application-Layer Protocol" but
>>> "Negotiation *of* Application-Layer Protocol". We couldn't name ALPS
>>> after the former because ALPN was already taken and it's a bit ambiguous.
>>>
>>>
>>>
>>>> maybe what I *want* is a brand-new ALSN (Application-Layer Stuff
>>> Negotiation) which would encompass ALPN and also QPACK static table
>>> negotiation and anything else which needs to be negotiated.
>>>
>>>
>>>
>>> If you work through that design, I think you will quickly reinvent
>>> something akin to the ALPN + ALPS combo.
>>>
>>>
>>>
>>> Yeah, I'm aware of that :) It was meant somewhat (OK, almost entirely) in
>>> jest...
>>>
>>>
>>>
>>>
>>>
>>> Really all this is just the standard set of tradeoffs in protocol design
>>> between minting new top-level versions or optional extensions within a
>>> version:
>>>
>>>
>>>
>>> - If we think this is just a sequential series of infrequently updated,
>>> essentially universal features, this can be rolled up into h2.1, h2.2,
>>> h2.3, etc., once we've settled on a cadence/criteria for how often we want
>>> to mint new ones of these.
>>>
>>>
>>>
>>> - If we think there may be multiple static tables for different folks, or
>>> that we want to define new ones frequently, or that maybe one might want to
>>> not have a static table at all, these tables may need to be one of several
>>> orthogonal features. We don't have a great story for this in h2 and h3
>>> today. ALPS aims to fill that gap, and fill in a few papercuts we left in
>>> h3 around how SETTINGS and 0-RTT tickets interact.
>>>
>>>
>>>
>>> I admit I've only been lurking in the half-rtt data discussion.
>>>
>>>
>>>
>>> TBH, in many ways it would make sense to use the ALPS as defined in
>>> https://www.ietf.org/archive/id/draft-davidben-tls-alps-half-rtt-00.html#name-using-alps
>>> for my use-case (QPACK static table), since in that case the server sends
>>> the ALPS h2 settings first and the client effectively 'responds', so a
>>> negotiation would start from the server, if I understand correctly.
>>>
>>>
>>>
>>> FWIW, while I believe ALPS is the right starting point for problems
>>> shaped like the second case, I don't personally have any horse in whether
>>> new static tables should look like the first or second. The second seems
>>> perfectly defensible, once we've switched from "never defining new ALPNs"
>>> to "occasionally defining new ALPNs".
>>>
>>>
>>>
>>> Sorry, just noticed that I mixed up "first" and "second" here. (This is
>>> what I get for referencing things by numbers!) That was probably confusing.
>>> I meant to say that the *first* seems perfectly defensible. That is, I
>>> think:
>>>
>>> - *If* you want to model this as lots of orthogonal features, something
>>> ALPS-y is the right shape.
>>> - But just rolling up common static table updates into h2.1, h2.2, etc.,
>>> whenever we find we need to mint new ones, seems likely fine.
>>>
>>>
>>>
>>> Which is fine by me.
>>>
>>>
>>>
>>> My concern is really about us having defined how h3 headers should be
>>> sent (QPACK, combo of static and dynamic tables) but not having a mechanism
>>> to extend that going forwards for specific use-cases.
>>>
>>>
>>>
>>> IMO, the worst-case scenario is where different client/server vendors
>>> (e.g. Apple, Amazon, etc.) decide to create their own additional static
>>> table entries (or simply much smaller and more limited static tables) in an
>>> effort to reduce bytes on the wire for things like assistants (Siri, Alexa,
>>> etc.) which only send a few headers, several of which are vendor-specific
>>> and which only contact servers which are expecting those requests. For each
>>> individual vendor, doing that would absolutely make sense and I wouldn't
>>> blame them for doing that, but overall it would make it much more complex
>>> to design common testing tools or utilities like cURL or simply to maintain
>>> some sort of standardization.
>>>
>>>
>>>
>>> Right, I think that's the ALPN vs ALPS question. If we believe a mess of
>>> vendor-specific static tables is worthwhile, we should do this with as
>>> subfeature and do something like ALPS. If we don't believe this is that
>>> important, and that we can live with a single, infrequently-updated,
>>> universal static table, let's just define h2.1 and move on with life.
>>>
>>>
>>>
>>> Given that the dynamic mechanism already compresses repeat headers after
>>> the first utterance, and that h2 and h3 are quite good at connection reuse,
>>> I suspect the h2.1 path is just fine. Or are you seeing that people are
>>> trying to make vendor-specific static tables already? I've not heard of
>>> this happening.
>>>
>>>
>>>
>>> David
>>>
>>>
>>>
>>> On Mon, Nov 27, 2023 at 1:12 PM Rory Hewitt <[e-mail]>
>>> wrote:
>>>
>>>
>>>     - Bumping this to request some input on my changes...
>>>
>>> FWIW, I'm inclined to come out against the idea of using ALPS rather than
>>> a TLS extension, primarily because ALPS is specifically NOT designed to be
>>> a negotiation mechanism. Of course basic ALPN IS a negotiation mechanism
>>> (it's right there in the name!), so maybe what I *want* is a brand-new ALSN
>>> (Application-Layer Stuff Negotiation) which would encompass ALPN and also
>>> QPACK static table negotiation and anything else which needs to be
>>> negotiated. It could probably include ALPS as well, since that could just
>>> not use the 'negotiation' concept... But I fear that's a pipe dream :)
>>>
>>>     -
>>>     - *From*: Rory Hewitt <[e-mail]
>>>     <[e-mail]?Subject=Re%3A%20The%20qpack_static_table_version%20TLS%20extension%20(Draft%20version%2002)&In-Reply-To=%3CCAEmMwDyy2hHfAN3gWWyyKRNFDUJ9i9aDgb%3DciEcEYrJOFzxcKA%40mail.gmail.com%3E&References=%3CCAEmMwDyy2hHfAN3gWWyyKRNFDUJ9i9aDgb%3DciEcEYrJOFzxcKA%40mail.gmail.com%3E>
>>>     >
>>>     - *Date*: Thu, 9 Nov 2023 16:03:23 -0800
>>>     - *To*: HTTP Working Group <[e-mail]
>>>     <[e-mail]?Subject=Re%3A%20The%20qpack_static_table_version%20TLS%20extension%20(Draft%20version%2002)&In-Reply-To=%3CCAEmMwDyy2hHfAN3gWWyyKRNFDUJ9i9aDgb%3DciEcEYrJOFzxcKA%40mail.gmail.com%3E&References=%3CCAEmMwDyy2hHfAN3gWWyyKRNFDUJ9i9aDgb%3DciEcEYrJOFzxcKA%40mail.gmail.com%3E>>,
>>>     TLS List <[e-mail]
>>>     <[e-mail]?Subject=Re%3A%20The%20qpack_static_table_version%20TLS%20extension%20(Draft%20version%2002)&In-Reply-To=%3CCAEmMwDyy2hHfAN3gWWyyKRNFDUJ9i9aDgb%3DciEcEYrJOFzxcKA%40mail.gmail.com%3E&References=%3CCAEmMwDyy2hHfAN3gWWyyKRNFDUJ9i9aDgb%3DciEcEYrJOFzxcKA%40mail.gmail.com%3E>>,
>>>     "Hewitt, Rory" <rhewitt=[e-mail]
>>>     <rhewitt=[e-mail]?Subject=Re%3A%20The%20qpack_static_table_version%20TLS%20extension%20(Draft%20version%2002)&In-Reply-To=%3CCAEmMwDyy2hHfAN3gWWyyKRNFDUJ9i9aDgb%3DciEcEYrJOFzxcKA%40mail.gmail.com%3E&References=%3CCAEmMwDyy2hHfAN3gWWyyKRNFDUJ9i9aDgb%3DciEcEYrJOFzxcKA%40mail.gmail.com%3E>
>>>     >
>>>     - *Message-ID*: <CAEmMwDyy2hHfAN3gWWyyKRNFDUJ9i9aDgb=
>>>     [e-mail]>
>>>
>>> Hey folks,
>>>
>>>
>>>
>>> Following my presentation at the meeting at IETF 118 today (thanks for
>>>
>>> taking it easy on me, as this was my first IETF appearance as well as being
>>>
>>> my first I-D), I have created another version of my I-D:
>>>
>>>
>>>
>>> https://www.ietf.org/archive/id/draft-hewitt-ietf-qpack-static-table-version-02.html
>>>
>>>
>>>
>>> Significant changes from version-01 are as follows:
>>>
>>>
>>>
>>> 1. I changed references to registry "Version" to "Variant" to make it clear
>>>
>>> that they could be very different.
>>>
>>>
>>>
>>> 2. I added a section on vendor-defined registries, which would contain
>>>
>>> static tables that might be much smaller and/or contain vendor-specific
>>>
>>> field names or values - for instance for personal assistants and APIs which
>>>
>>> only use a very small set of headers with known values.
>>>
>>>
>>>
>>> 3. In the QPACK Static Table Background
>>>
>>> <https://www.ietf.org/archive/id/draft-hewitt-ietf-qpack-static-table-version-02.html#name-qpack-static-table-backgrou>
>>>
>>> section,
>>>
>>> I added an example showing how the use of a static table can significantly
>>>
>>> reduce bytes on the wire by passing only 2- or 3-byte references to much
>>>
>>> longer strings that are known to both client and server.
>>>
>>>
>>>
>>> 4. The details of the TLS extension has been changed so that it is no
>>>
>>> longer simply a Variant/Length pair, but similarly to ciphersuite support,
>>>
>>> it is (when passed in the ClientHello) an array of Variant/Length
>>>
>>> combinations supported by the client and (when passed in the ServerHello) a
>>>
>>> single negotiated Variant/Length pair which will be used by both client and
>>>
>>> server.
>>>
>>>
>>>
>>> Note that the draft still refers to this as a "TLS extension" - I think
>>>
>>> many of us agree that it would be preferable if it were defined in ALPS,
>>>
>>> but since ALPS support is still minimal, I'll keep referring to it as a TLS
>>>
>>> extension for now. Given that, I would really appreciate any comments on
>>>
>>> the high-level concept, on the understanding that it may not end up being a
>>>
>>> TLS extension. Speaking of which, where can I find details of why ALPS was
>>>
>>> not taken up - it was mentioned in the meeting that there were 'concerns'
>>>
>>> about ALPS, but I'm not clear on what they were or who was concerned - HTTP
>>>
>>> WG or TLS WG or both or some other entity?
>>>
>>>
>>>
>>> Finally, I'm still trying to build a test harness to determine whether the
>>>
>>> benefits of any additional compression make sense - is this even worth the
>>>
>>> hassle? I would greatly appreciate any help on this - you'll get co-author
>>>
>>> credit, for what that's worth :)
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Rory
>>>
>>> *Received on* Friday, 10 November 2023 00:03:41 UTC
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Rory Hewitt
>>>
>>> https://www.linkedin.com/in/roryhewitt
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Rory Hewitt
>>>
>>> https://www.linkedin.com/in/roryhewitt
>>>
>>
>>
>> --
>> Rory Hewitt
>>
>> https://www.linkedin.com/in/roryhewitt
>>
>