On Mon, Jul 20, 2020 at 5:00 PM Lucas Pardue <[email protected]> wrote:
> On Mon, 20 Jul 2020, 21:38 David Benjamin, <[email protected]> wrote: > >> On Mon, Jul 20, 2020 at 3:33 PM Victor Vasiliev <vasilvv= >> [email protected]> wrote: >> >>> On Mon, Jul 20, 2020 at 3:10 PM Lucas Pardue <[email protected]> >>> 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
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
