Re: [TLS] Application-Layer Protocol Settings

On Mon, Jul 20, 2020 at 5:00 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> On Mon, 20 Jul 2020, 21:38 David Benjamin, <davidben@chromium.org> wrote:
>
>> On Mon, Jul 20, 2020 at 3:33 PM Victor Vasiliev <vasilvv=
>> 40google.com@dmarc.ietf.org> wrote:
>>
>>> On Mon, Jul 20, 2020 at 3:10 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
>>> wrote:
>>>
>>>> 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.
>>>>
>>>
>>> It explicitly bans all existing frames that are not SETTINGS.  The
>>> problem here is that SETTINGS only supports integral values, so we'd be
>>> limited to those if we make ALPS just SETTINGS.
>>>
>>
>> Right, concretely there is an "Allowed in ALPS" column added by Victor's
>> ALPS document, which my document sets for the new frame. Old frames weren't
>> designed with ALPS in mind, so the ALPS document needs to make a decision.
>> New frames can reason about the implications of opting into ALPS and do so.
>>
>> As Victor notes, it's only a new frame because we got SETTINGS values
>> wrong and, per earlier discussion, the extension point we currently have is
>> new frames. If we want something even more restrictive, we could instead
>> revive draft-bishop-httpbis-extended-settings, say only SETTINGS and
>> EXTENDED_SETTINGS are allowed, and close it there. But I think the new
>> column works fine and matches how this sort of thing usually works.
>>
>
> 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