Re: [TLS] Application-Layer Protocol Settings

[Lucas Pardue <[e-mail]>]

Hi Victor,

It seems my brain skipped over "ALPS in HTTPS" [1] when you mentioned in
your original email. I was reading it in the context of David Benjamin's
thread on Client Hint Reliability [2]. There's a couple of things that
surprised me when reading both drafts:

1. ALPS in HTTPS actually supports more than just exchanging Settings
Parameters, it can actually hold a series of frames. It's just that ALPS
only defines SETTINGS to be allowed, and Client Hints Reliability wants to
add more in the shape of a new ACCEPT_CH frame. I'm not sure I like the
idea of supporting any old frame in the TLS handshake, SETTINGS are at
least reasoned about in terms of how they are remembered for the purposes
of 0-RTT.
2. ALPS in HTTPS makes it mandatory to support some settings to disable
static and Huffman header compression. That seems pretty onerous. If there
was interest in prototyping something like ACCEPT_CH-in-handhsake it
requires a modification of a QPACK dependency. On the other hand, if you
don't make these settings mandatory, then you won't achieve your objective
of removing the mandatory parts of HPACK/QPACK. To me this is a signal that
ALPN is a better option to negotiate a profile of H2/H3 that modifies
mandatory compression behaviour.

Cheers
Lucas


[1] https://tools.ietf.org/html/draft-vvv-httpbis-alps-00
[2] https://lists.w3.org/Archives/Public/ietf-http-wg/2020JulSep/0054.html