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

Hi Rory,

I echo Watson and Martin, lets discuss this in the HTTP WG.

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?

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.

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.

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.

Cheers,
Lucas

[1] - https://datatracker.ietf.org/doc/html/draft-vvv-tls-alps





On Wed, Sep 27, 2023 at 1:40 AM Martin Thomson <mt@lowentropy.net> wrote:

> On Wed, Sep 27, 2023, at 01:32, Hewitt, Rory wrote:
> > Apologies if I should respond directly to the mailing list - my old W3C
> > profile has disappeared and I'm trying to get it back...
>
> Just on this point.  Watson added the HTTP working group, which I think is
> the right thing to do here.  The maintenance of HTTP/3 now formally belongs
> in that group.  The work of defining a TLS extension for that purpose would
> occur there (if indeed a TLS extension is the right choice, as Watson asks).
>
> As for the W3C involvement, the HTTP working group is an IETF activity
> that - for historical reasons - uses a W3C-hosted mailing list.  You don't
> need to be a W3C member to sign up for that list.  The process is just a
> little different than for other IETF lists.  See
> https://lists.w3.org/Archives/Public/ietf-http-wg/ for details.
>
>