Re: [TLS] Application-Layer Protocol Settings

On Tue, Jul 21, 2020 at 8:22 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

>
> On Mon, Jul 20, 2020 at 10:42 PM David Benjamin <davidben@chromium.org>
> wrote:
>
>> On Mon, Jul 20, 2020 at 5:00 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
>> wrote:
>>
>>>
>>> That makes sense but I guess I don't see the point in defining a new
>>> thing that contains frames that are never sent on streams. That is, if
>>> these are connection settings, just send the payload. Unframed extended
>>> settings might get you there, if you can find a way to encapsulate
>>> conventional settings inside them, then all the better.
>>>
>>
>> Could you elaborate on this a bit? I'm probably just failing to parse,
>> but I'm not sure which alternative you're suggesting here. (Ah, the wonders
>> of email.)
>>
>> David
>>
>
> I was trying to accommodate HTTP/2 and HTTP/3 in one breath, which is why
> my intent was probably unclear. Basically, if ALPS relies on frames for
> per-protocol settings then it has to accommodate the differences in frame
> format between HTTP/2 and HTTP/3. In the examples from the ALPS and Client
> Reliability proposals, the H2 frame needs to populate the frame header and
> it pick stream 0, which doesn't exist until the connection is actually
> made, so seems a bit kludgy. In H3, frames don't have the stream ID so you
> avoid the problem above.
>
> So my thought was to basically do away with the notion of
> protocol-specific frames in ALPS, and instead define the a common payload
> format that perhaps looks something like bishop-extended-settings [1], a
> series of Type-Length-Value (but without any frame headers). This would
> allow you to encode the old and new settings in a single format, rather
> than needing to delineate things via frames.
>
> [1] -
> https://tools.ietf.org/html/draft-bishop-httpbis-extended-settings-01#section-3.1.1
>

Ah, gotcha. The thinking was the settings were ALPN-specific anyway, so we
may as well define them however is more idiomatic for the protocol. This
means we automatically can make existing H2 and H3 settings more reliable.
Settings values can also be updated over the course of the connection, so
using frames keeps continuity there. But, yeah, a separate key/value syntax
would work too.

(A small correction, the current Client Hint Reliability proposal allows
ACCEPT_CH to be sent in application data too. Maybe the frontend realizes
the origin's ACCEPT_CH preferences have changed and wants to notify
existing connections. Though I don't consider this feature important. I
doubt most folks, if anyone, will bother with this. Mostly that's how a
SETTINGS or EXTENDED_SETTINGS value already would have worked, so I figured
the semantics ought to be compatible in case EXTENDED_SETTINGS is revived.)

David