Re: [TLS] Application-Layer Protocol Settings

[Lucas Pardue <[e-mail]>]

On Mon, 20 Jul 2020, 21:38 David Benjamin, <[e-mail]> wrote:

> On Mon, Jul 20, 2020 at 3:33 PM Victor Vasiliev <vasilvv=
> [e-mail]> wrote:
>
>> On Mon, Jul 20, 2020 at 3:10 PM Lucas Pardue <[e-mail]>
>> 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.

Cheers
Lucas


/tls <https://www.ietf.org/mailman/listinfo/tls>
>>
>