- From: Victor Vasiliev <vasilvv@google.com>
- Date: Mon, 6 Jul 2020 15:12:45 -0400
- To: "tls@ietf.org" <TLS@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAAZdMaf2dKab0dJU8MLZc9JzEcVSvf8s9kgeZFo3tmsRtx2sNQ@mail.gmail.com>
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.
Received on Monday, 6 July 2020 19:13:14 UTC