Re: [TLS] Application-Layer Protocol Settings

Martin Thomson <> Wed, 08 July 2020 01:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ECC633A0CFE for <>; Tue, 7 Jul 2020 18:31:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=BiHLoTJA; dkim=pass (2048-bit key) header.b=bKfB7yUu
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5VHiEPd8vg1K for <>; Tue, 7 Jul 2020 18:31:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 90D043A0CF9 for <>; Tue, 7 Jul 2020 18:31:42 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jsytE-0001jK-DH for; Wed, 08 Jul 2020 01:28:48 +0000
Resent-Date: Wed, 08 Jul 2020 01:28:48 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jsytD-0001iZ-BQ for; Wed, 08 Jul 2020 01:28:47 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jsytB-0003CZ-6u for; Wed, 08 Jul 2020 01:28:47 +0000
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 965C25C0158; Tue, 7 Jul 2020 21:28:33 -0400 (EDT)
Received: from imap2 ([]) by compute2.internal (MEProxy); Tue, 07 Jul 2020 21:28:33 -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:content-transfer-encoding; s=fm2; bh=U+bVV qL4pk7Qw5A3wMDyQpu3TXdtSHeljKa0jRigg+k=; b=BiHLoTJAy9VvkU6Ednidw roqKWnuRB/WR1nrAEL5mn0ACHb2wLhOb2pjkE12UcRGmXiWVMC7bscyRSgEpfECT 909BiiZS0RoDn6m1NwM4GyZ9HmmwA0UiqUTe1yu3xBltEQwSv4w+Q3UnqqLY+UV8 5youxUrZLaGj7B3GHXcP66FtLkv0JoxP7hOEBceqKMoDF9AHc9CzUrXkI6YMXCN7 vXMUV+/nTSML5k2GOKKVB88RdNwew4BAysnz1YgHGDdq2xFg1AkkCY8YQjrAdILh /V1zRQwCmNIcbzMeZHSkvR5IMqGuQvuaYHv9wpLSxj70raR9KfYaMFkO9ZUCiWWD g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding: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=U+bVVqL4pk7Qw5A3wMDyQpu3TXdtSHeljKa0jRigg +k=; b=bKfB7yUuPx0KRW1I0vyN05YRYQzHOTYnx+uRWk6yi3xgTyh8y9Azmt8Fy J6PXupYZSlGlgGXCPUN2y8TiCI6aQkZUewSLS5nqPg2BkfvZ6VLni9U64/0GYI3r +FmGkmHh4C8ofQOn13wxPkfly1a3SA3bIfRwVI32L72gcn+ByR0vzkCUTckGLXxD o+pBLnkBm9hrGxn2xVGSK7FgImU/+eHn/MagqtN1vF7eAMKxy5LjuAX5iFoiJ+pb xMwRl5/ZNFmQ+SBfupbkZVabZVHfsou4N/JyoOiRxGQBAss2/6S+uVSI8QSDUuIu NMMBcKrd2OrzLuCfOUakTAsADld4A==
X-ME-Sender: <xms:QSEFX0aW3M9RPS2zGcfXUr-77YWIt8Ao2-diiNFZ76Ex6ILGAG6ZiA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudeigdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhephfdvieehveehkeehteethedthfelkedvtdetjeelgeegjedujeeg ueffleejgfevnecuffhomhgrihhnpehhthhtphdvrdhimhdpihgvthhfrdhorhhgpdiffe drohhrghdphhhtthhpohhrrghtlhhsqdhlvghvvghlvghnughofhhhrghlfhdqrhhtthgu rghtrgguvghlihhmihhtvghrrdhnohifpdhgihhthhhusgdrtghomhdphhhtthhpfehthh hishhhrghsshhomhgvihhntghrvghmvghnthgrlhgvfhhfvggtthgsvgihohhnughthhgr thdrihhnpdhhthhtphhsvghtthhinhhgshhfrhgrmhgvihhnthhothhhvghtlhhshhgrnh gushhhrghkvgdrhhgvrhgvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:QSEFX_b7bDSWAN5khnrY-L9II6cYVVw0XdSxgWN8jRHQsAIotf81pg> <xmx:QSEFX--j7s5uhM1TwGKMjparNvLfJnHzz9LnqZDSTKzCuYmvvk11XQ> <xmx:QSEFX-ryGyr3PlT3q-ZNNq-NXWwE-EQHQtjDCrM7wpjKZdHavxViUg> <xmx:QSEFX5F33Bb1TFkygQwdk-GhUihoPypmOOIRodt3SA9VnmwuZLSJPA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1C6E8E00E3; Tue, 7 Jul 2020 21:28:33 -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: Wed, 08 Jul 2020 11:28:13 +1000
From: "Martin Thomson" <>
To:,, "David Benjamin" <>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-9.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1jsytB-0003CZ-6u 57b21471b8d50b99e7e88c87fc11c898
Subject: Re: [TLS] Application-Layer Protocol Settings
Archived-At: <>
X-Mailing-List: <> archive/latest/37853
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi David,

I think that there is an important difference between something that is hard to realize in practice (as many aspects of this clearly are) and using that to say that the fundamental protocol definition is wrong.

I appreciate - at least superficially - the complexities involved here.  Having implemented them, and having worked around many of the problems you have identified, it was not trivial to implement 0-RTT or 0.5-RTT (the latter was pretty-much trivial for much the same reason that false start works, but I'll concede that I probably didn't fully explore all of the potential problems).

But as much as recognizing implementation complexity is important, that doesn't necessarily translate into a requirement to change the protocol.

Let's take an example of a feature you are trying to negotiate in HTTP (/2 or /3).  I don't think that it is unreasonable to say to a client that it cannot attempt anything that depends on this feature until it receives SETTINGS.  You can then require servers that support this extension to send SETTINGS in 0.5-RTT so that the client is only blocked on the extra bytes and not additional round trips.  All of which implies that you need TLS 1.3 for the feature.

The drawback there is that the client that wants to use the feature might not receive the SETTINGS in time and they don't get a clear indication that this is not happening.  Ben's suggestion to use a new version if you care about avoiding that case is entirely appropriate.  It depends on what sort of extensions are being contemplated here to determine whether this is indeed necessary.  I tend to think a h2_tls13 ALPN that mandated use of 0.5-RTT for SETTINGS would put a big dent in this negotiation problem.

Either way, your stack might require new changes to support the writing of some fixed amount of data on all new connections.  This might turn into a requirement on TLS terminators to have per-backend configuration to support this new information.  But these don't necessarily turn into new protocol mechanisms.  Indeed, these changes are far less disruptive overall than a completely new TLS extension, particularly if the TLS extension involves all of the same coordination.

I concede that saying that SETTINGS is sufficient isn't free, and that there is some additional cost on implementations.  On the other hand, the "cost" is that implementations improve some aspects of an existing protocol that provide other benefits to those implementations.

On the other hand, new mechanisms like this require the same amount of coordination, more work at the TLS layer, and all the delays imposed by standardization.

On Wed, Jul 8, 2020, at 05:11, David Benjamin wrote:
> Hi Martin,
> You’re right that this is closely related to half-RTT data. However, I 
> don’t think this is a no-op for HTTP/2.
> I’m not aware of HTTP/2 clients that wait for the SETTINGS frame today. 
> Doing so costs a round-trip with servers that don’t send SETTINGS in 
> half-RTT, and there's no indicator for whether the server will send it. 
> I’ll see about testing some sites here and will report back, but I 
> expect most do not. We (correctly) designed TLS 1.3 as a drop-in 
> replacement for TLS 1.2, which means that we don't get to key new I/O 
> patterns on it. Half-RTT data is a very weird state and wouldn’t get 
> used by default. This is the problem with “no standards change is 
> required” style of thinking around simply changing I/O patterns. A 
> protocol is more than its wire image. Changing the I/O patterns is a 
> protocol change.
> This means we cannot get efficient and reliable feature negotiation 
> today. Moreover, HTTP/2 servers today may send ServerHello..Finished 
> without application data in their first flight, so we need *some* 
> change to the TLS flight, be it ALPS or just some indicator.
> Let’s look at what it’d take to make half-RTT SETTINGS work. We need 
> some “I will send half-RTT data, so you can safely wait for it” 
> indicator. Then the client needs to know when it is done waiting. We 
> could say it’s one SETTINGS frame, but that only allows integer values. 
> <> and discussion <>.) Those currently need separate frames, and one cannot wait for the absence of a frame. Maybe we need an HTTP-level SETTINGS_WILL_SEND_HALF_RTT_XYZ_FRAME indicator to keep the delimiter in HTTP, or a TLS-level “end of half-RTT data” delimiter. (Now consider how that works in QUIC...)
> Next we need to tackle 0-RTT. Waiting for half-RTT data costs a 
> round-trip in 0-RTT, so we need something to persist across the 
> session, with semantics around mismatch and whatnot. (Another 
> TLS-visible change.) Anything persisted in the session must have 
> bounded size, and be delivered in something ordered with 
> NewSessionTicket.
> If we place those bytes inside the handshake, we’ve reinvented ALPS. If 
> we place them outside, the NewSessionTicket ordering becomes complex, 
> especially in QUIC 
> <>. To your question about the server repeating its configuration vs. the client remembering it, I believe the issue was exactly that ordering mishap. ALPS avoids this because EncryptedExtensions and NewSessionTicket are ordered.
> On top of this, the half-RTT point in a non-0-RTT connection is a weird 
> state. Not all connection properties (e.g. client certs) have been 
> established yet, and writes out of turn are tricky. This message 
> <> discusses some of the challenges here. I would argue something like ALPS is the settings design we should have had all along.
> David
> On Tue, Jul 7, 2020 at 1:10 AM Martin Thomson <> wrote:
> > 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
> >  >
> >  >
> >  >
> > 
> >  _______________________________________________
> >  TLS mailing list
> >
> >