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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
