RE: [TLS] New Internet Draft: The qpack_static_table_version TLS extension

Hey Lucas,

Some response thoughts in-line...

> As for a very brief technical response. In general I'm supportive of the
> idea of more agility of the static table but I think my motivations would
> be different than the ones behind this proposal. For me, I'd like more
> domain-specific tables to be defined, and to have the possibility of
> asymmetric tables; but lets stick that on the side for now.
> The QPACK static table description states "The order of the entries is
> optimized to encode the most common header fields with the smallest number
> of bytes.". How does the proposed append-only table gel with this? I.e.
> each year, the new most common fields are added to the end? At what point
> would it make sense to wipe out the cruft and define a newer table
> altogether?


My original design was that rather than have a simple UInt8 (e.g. 99, 114,
146) that there would be both a version and a count held in a single UInt16
- so the default original value is 01099, followed by e.g. 01114, 01146
etc. At some point, the table is reordered to put the new commonly-used
headers at the beginning and we move to 02146 - same number of entries as
in 01146 but reordered to be more efficient with 'new' commonly-used
headers moved to the beginning of the table. The same process to match on
lowest shared version can still be used since the comparison can just be on
the integer value. But then I wondered whether that was just getting too
complex - flexibility at the cost of complexity.


Indeed, various domain-specific tables COULD be defined using a similar
scheme, e.g. in a UInt16 we use left 4 bits to identify domain (0=general),
next 4 bits identify version, next 8 bits identify entry count. So 01146 is
"general domain, version 1, 146 entries" whereas 32043 is "media domain,
version 2, 43 entries" and so on.


I think what might be needed is a good amount of datamodelling and
> simulation that is sufficient to decide when there is activation energy to
> make changes. Perhaps the proposal is a compromise to make it low effort
> enough for implementations to update, that they don't need tremendous
> amounts of overwhelming evidence to keep up. IIRC historically the effort
> to sample the Internet and propose a table has been quite high, and there
> have been some criticisms about the outputs. Given the HTTP WG has
> struggled with this aspect, I think it is decidedly impractical to make
> IANA or a designated expert solely responsible for deciding the QPACK
> entries. This is something that has to run through a consensus approach
> IMO, especially as lower entries are more valuable and couldn't ever be
> reclaimed.



A lot of the info is already available through the efforts of folks like
Barry Pollard and the HTTP Web Archive, who I worked with when writing the
caching chapter in 2020. So it would be relying on a 3rd-party to do the
work to provide a representative sampling of web traffic, but the data
certainly exists.


I think the largest activation energy would be to convince endpoints to
> implement the negotiation mechanism because it is pushing it into the TLS
> layer and that crosses implementation boundaries. Watson asks why not
> SETTINGS. One answer is that it requires clients to have to wait for the
> server's settings, which adds a delay that many clients don't already
> apply. Trading off latency for a few bytes doesn't sound like a good
> tradeoff. Indeed, this is why we optimised the static table for the
> clien'ts first flight before it knows if the server supports dynamic QPACK
> or not. Putting a client's static QPACK preference in a Client Hello is a
> fingerprinting vector, so that is a concern. Perhaps a middleground is to
> use a SETTING but then rope in the old ALPS proprosal [1] so that the
> client learns the server's view as early as required, and the client sends
> its view in SETTINGS after protection is established.


I too have concerns about putting this into the TLS layer, and likely ALPS
is a better choice (it's the one that Mike Bishop originally suggested when
I discussed my concerns with the existing static table with him and raised
an errata against RFC9204 [2]. I personally don't think the static table
info in Client Hello is a 'significant' fingerprint concern - at most it
might show that an individual is using a particularly old/new version of a
browser, but I foresee that almost all browsers use 99 for a long time and
then move up to whatever the next value is pretty much at once.



> Changing track a bit, I don't understand why your proposal requires the
> client and server to agree on the extension value. Its a declaration of
> what the endpoint can support and I don't think there is any issue in e.g.
> the client being willing to receive references to entries greater than 99
> and the server refusing to. Encoding asymmetry is already part of QPACK DNA.


I prefer the lowest common denominator approach. If a server can support a
static table length of 114 and the server only supports 99, then surely the
client MUST NOT send a static table entry of 100 (which it understands)
because the server has no idea of what that means.


Rory


[1] - https://datatracker.ietf.org/doc/html/draft-vvv-tls-alps
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-vvv-tls-alps__;!!GjvTz_vk!WZ-KJ2NZw0Hvc3InAsS00CJwTCMK7VcSjtV3mOQ-t0F0l7riNz7Pa9aO2_5EO_6i5eBjC_SvwudLq1KhyT-F1vjV$>
[2] - https://www.rfc-editor.org/errata/eid7277