Re: [TLS] Application-Layer Protocol Settings

Ilari Liusvaara <> Tue, 07 July 2020 09:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14A6E3A07A2 for <>; Tue, 7 Jul 2020 02:06:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 43MkLubUMa89 for <>; Tue, 7 Jul 2020 02:06:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 802A93A07A0 for <>; Tue, 7 Jul 2020 02:06:52 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 340CA16831; Tue, 7 Jul 2020 12:06:50 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id Sn67VxHMyBJe; Tue, 7 Jul 2020 12:06:50 +0300 (EEST)
Received: from LK-Perkele-VII ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id E9C98286; Tue, 7 Jul 2020 12:06:46 +0300 (EEST)
Date: Tue, 07 Jul 2020 12:06:46 +0300
From: Ilari Liusvaara <>
To: Victor Vasiliev <>
Cc: "" <>, HTTP Working Group <>
Message-ID: <20200707090646.GA153416@LK-Perkele-VII>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [TLS] Application-Layer Protocol Settings
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Jul 2020 09:06:55 -0000

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).