- From: Ilari Liusvaara <ilariliusvaara@welho.com>
- Date: Tue, 7 Jul 2020 12:06:46 +0300
- To: Victor Vasiliev <vasilvv@google.com>
- Cc: "tls@ietf.org" <TLS@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Jul 06, 2020 at 03:12:45PM -0400, 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: I note at least two people have proposed just fixing TLS stacks to allow sending HTTP/2 SETTINGS in 0.5-RTT data. I used to have a server that actually did that (only if there was no CertificateRequest, due to interface limitations, this was not TLS library limitation). Unfortunately, this is not quite interoperable. There are HTTP/2 clients out there that just puke (with unexpected_message TLS alert, sent post-Finished) if one tries to send SETTINGS in 0.5-RTT data. I do not know what clients are involved (IIRC, I have heard about problems with at least Firefox and Chrome, versions unknown), but I would presume some sort of MITM by some client software is involved. That was quite painful to debug. Much nastier than e.g., debugging handshakes failing with illegal_parameter due to downnegotiation gone wrong due to server bug (this client is still using TLS 1.3 draft 23, and is still out there). -Ilari
Received on Tuesday, 7 July 2020 09:07:05 UTC