Re: [TLS] Application-Layer Protocol Settings

David Benjamin <> Tue, 07 July 2020 19:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 418083A0A2B for <>; Tue, 7 Jul 2020 12:14:56 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KjTPQJghFBia for <>; Tue, 7 Jul 2020 12:14:53 -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 077BE3A0A63 for <>; Tue, 7 Jul 2020 12:14:51 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jst0R-0006iJ-UC for; Tue, 07 Jul 2020 19:11:52 +0000
Resent-Date: Tue, 07 Jul 2020 19:11:51 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jst0Q-0006hY-PX for; Tue, 07 Jul 2020 19:11:50 +0000
Received: from ([2607:f8b0:4864:20::102d]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jst0O-00012z-Ks for; Tue, 07 Jul 2020 19:11:50 +0000
Received: by with SMTP id k5so85173pjg.3 for <>; Tue, 07 Jul 2020 12:11:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AxSEHCyku+hRfWl/qyihecqy+ApKO24ym4hGsL8IhY8=; b=aPlWccx7LQNlF1FT2bQz5FPfmUllhE+/Kw42HFwg/LVrW2SikUdMc4J/Fd86lzCRO3 oL6OtdEcMxfczfPpkWChfn2tw4hUC0d4m+KLOzfBK4UIGFbAaXB2QJ6IY0t1ToeZKbfw fH2Ka6kJ/TcO7Gg2npBZI9pGgTDZxVBcFccZ0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AxSEHCyku+hRfWl/qyihecqy+ApKO24ym4hGsL8IhY8=; b=OCFQbcp2PT4JD939aYbk6BUXeB6L2FV/JopGuq3yzjYmK7jdtPQBGokNemuQChz5hJ EIwK+CVT5F98STXPSpuJmvdWXDlVRG7JLLpzuo1qq1bd5zaQYlu/pv92RGknOqmNQZOB 8yt1kE/cdMDTtSR797+N2/h1vCe2uLUgR8hvN2aCvNJ7iN45rV7W1dXq3LRJCjO6EBbv ztL6Fgyx4y7IvmcXDVr/8Fvknwb8hCaGC5TCFK8zO2ZfKI+WV7IGncdh/h76tBTzRpQc ZF+HIVZS3G7jzHOWTFKjJ5vJPLVuZZeBiRBNjqkFCXRzw6nC4JwvcNbBMSAQPxjSqgZC 7r/g==
X-Gm-Message-State: AOAM532hVX9PTz1Vy5qdYl4uA8WdMe0hOcBDWrCWbQXzf11fqtgl4v3/ wJKE1H4QNsQu9uEYlDkFSlUDJ7VwijVglOc2LLwk
X-Google-Smtp-Source: ABdhPJxEg9DqPNb8jEZMpTCglVD/haa/eMwEMsRxV31NeydCQOv1Z5Mg106ZFeTfUvZtMlA3u21v29ZvTj0kWUJne3s=
X-Received: by 2002:a17:90a:aa83:: with SMTP id l3mr5755713pjq.73.1594149097000; Tue, 07 Jul 2020 12:11:37 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Tue, 7 Jul 2020 15:11:20 -0400
Message-ID: <>
To: Martin Thomson <>
Cc: "<>" <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000a5b84605a9dec24a"
Received-SPF: pass client-ip=2607:f8b0:4864:20::102d;;
X-W3C-Hub-Spam-Status: No, score=-11.3
X-W3C-Scan-Sig: 1jst0O-00012z-Ks abe422e68f61f98cc04c21e979f77209
Subject: Re: [TLS] Application-Layer Protocol Settings
Archived-At: <>
X-Mailing-List: <> archive/latest/37849
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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. (Related:
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
some of the challenges here. I would argue something like ALPS is the
settings design we should have had all along.


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