Hi Victor, For HTTP/2, this is essentially a noop, as endpoints are required to send SETTINGS immediately. Whether these bytes appear before Finished or not only affects endpoints that aren't inclined to wait for SETTINGS. This is somewhat complicated by the way that TLS 1.2 and TLS 1.3 differ, but if we assume TLS 1.3 here, any uncertainty is easily avoided.
The main justification here appears to be based on the lack of 0.5-RTT send capability at some servers. I don't know how to assess whether the cost of greater integration with the TLS stack is preferable to fixing the 0.5-RTT send problem. For HTTP/3, this has some incremental effect beyond that. In effect, this deliberately introduces head-of-line blocking for settings. You can already do that in HTTP/3 if you are not prepared to deal with settings being in an ambiguous state. There's a little more determinism here in terms of where you look for the data that unblocks progress, but with retransmissions, this is not a difference worth worrying about. What this head-of-line blocking might allow is the development of new extensions that are unable to deal with uncertainty regarding SETTINGS. But isn't it also possible to address that problem by saying "if you implement extension X, then you MUST NOT send requests prior to receiving SETTINGS?" In QUIC, we decided that having the server repeat its configuration after 0-RTT was preferable to remembering it. This was after a non-trivial number of questions about that part of the specification. You seem to have taken the opposite approach. Is that deliberate? If so, why? On Tue, Jul 7, 2020, at 05:12, Victor Vasiliev wrote: > Hello TLS and HTTP working groups, > > (QUIC WG bcc'd as this has been discussed there before) > > Currently, we use SETTINGS frames as an extensibility mechanism in > HTTP/2 and HTTP/3. The SETTINGS frame is sent at the very beginning of > TLS application data; this approach, while simple, has some drawbacks. > The most notable one is that when SETTINGS are used to negotiate > extensions, there is an entire round-trip where the client can send > requests, but doesn't know yet about any server extensions, thus making > any extension-dependant requests take an extra RTT. > > The proposed solution to this problem is to move HTTP SETTINGS frame > into the TLS handshake. Here are some issues where this has been > discussed before: > * https://github.com/quicwg/base-drafts/issues/3086 > * https://github.com/quicwg/base-drafts/issues/3622 > * https://github.com/WICG/client-hints-infrastructure/pull/30 > I wrote up a draft for the TLS extension that would solve this problem: > https://tools.ietf.org/html/draft-vvv-tls-alps-00 > > I also wrote up a draft that explains how to use that extension with > HTTP, and defines some settings (the ones discussed here > <https://github.com/quicwg/base-drafts/issues/3622>) that would not be > possible without it: > https://tools.ietf.org/html/draft-vvv-httpbis-alps-00 > > I would appreciate feedback on those drafts. > > Thanks, > Victor. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
