Re: [TLS] Application-Layer Protocol Settings

Martin Thomson <> Tue, 07 July 2020 05:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1FBB23A082E for <>; Mon, 6 Jul 2020 22:10:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=EFgZ8EAY; dkim=pass (2048-bit key) header.b=egdaDnFj
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vR2bMtcwdLUw for <>; Mon, 6 Jul 2020 22:10:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5777B3A082D for <>; Mon, 6 Jul 2020 22:10:12 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 732DF5C01A4; Tue, 7 Jul 2020 01:10:11 -0400 (EDT)
Received: from imap2 ([]) by compute2.internal (MEProxy); Tue, 07 Jul 2020 01:10:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=x8BQAiTVDwFhaxF8SWRzcO1LWksQWbq EmTt5IfMifKs=; b=EFgZ8EAYxGf3H83uec5wYkVyvIyhRmuTxTJGu+7QfW1xwHY E8aOa5T3Ya0rvGO2VqfdTnIGnKbiUGsiLsfDbwXyZIukFXMrLvtI7L7S2aJDrl4D 9DP/y0dyfpQNph8K2lYSjpcAdlh3vVsGZUqE836EwhFZvpvJJBz03YQW9ev32M4k z+5XV7eJxQzP2Oi11rSdPEofcP4Yypjf43NU4gSg05Rq/tpQ7goyLTnT66bmOLxs g+2gMmWJAt7WEnrZKXCcHCu7JlgqLgT5nPQRLGkZ2PQYMzPiiyou5R54en8tWVPN dTVSVhQkRGE7B3ZnIXfvrSsKiN70rkxqQFDFBlA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=x8BQAi TVDwFhaxF8SWRzcO1LWksQWbqEmTt5IfMifKs=; b=egdaDnFj4Cm3bZVq5mDwiw lVq8t1Jroke6OrhCepnhYjzv9Am8+ZIvgWOT3sWbkdB8CNv5bP3pJ8J2Gm0/GeMX NF+kjzn6pNcODWfBS3C62wiheOzTTU5XNOdLlKbvgvPPjRtdm38LHed2/mCSSd6q Fe8jHPFSnocBvLi3qJrUoJoJAmsOaEQnLLBMVBfeRZziUSDQpBk6l+iD4YgfCcYq R7j/Ou4E0IxykKjT/f+B6bnM2Y/mA8uZfOz0v6cgNQDwLde8XLvInuIeEdJnUS39 TAvXXecmHWy4UGGVIYz1OsYM/Qs4jKIZCGyNhpZ7bSeNvNklVrBmiGrFPKNigU2w ==
X-ME-Sender: <xms:swMEX4uH0tMcaD_wbhiGQSe8dqtVkSFNeu2E6QDKcM7XNfLnE-9TBg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudeggdelgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepgfeuveevieffhfevheelie ejvdfgvdfhieettdffkeelkeegvdejgfeuudejleefnecuffhomhgrihhnpehhthhtphef thhhihhshhgrshhsohhmvghinhgtrhgvmhgvnhhtrghlvghffhgvtghtsggvhihonhguth hhrghtrdhinhdphhhtthhpshgvthhtihhnghhsfhhrrghmvghinhhtohhthhgvthhlshhh rghnughshhgrkhgvrdhhvghrvgdpghhithhhuhgsrdgtohhmpdhivghtfhdrohhrghenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhho figvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:swMEX1e0hBxiO-d_n2f85yGBE1FNE-mCp8Cls52qB85mz5hD2lX_Kw> <xmx:swMEXzxLGwiK3H6T-8r24AfbZqD7LcoWIua_XUw74oWljMODNbzauA> <xmx:swMEX7NcaqHwr0m0UHF7HX2Uy505eh7T8-i_xWYLI5UNmdCkd8ePbw> <xmx:swMEX7I4uoj94eSgYMmj_rdKbQefP05FdRqcBSonKmjXmisuZ92m0A>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0EEBFE00B3; Tue, 7 Jul 2020 01:10:11 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Tue, 07 Jul 2020 15:09:50 +1000
From: Martin Thomson <>
Content-Type: text/plain
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 05:10:14 -0000

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:
>  *
>  *
>  *
> I wrote up a draft for the TLS extension that would solve this problem: 
> I also wrote up a draft that explains how to use that extension with 
> HTTP, and defines some settings (the ones discussed here 
> <>) that would not be 
> possible without it: 
> I would appreciate feedback on those drafts.
> Thanks,
>  Victor.
> _______________________________________________
> TLS mailing list