Re: [TLS] Application-Layer Protocol Settings

Victor Vasiliev <> Wed, 08 July 2020 14:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36F033A0C25 for <>; Wed, 8 Jul 2020 07:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R1Pxa8VC6urZ for <>; Wed, 8 Jul 2020 07:14:04 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D82403A0D40 for <>; Wed, 8 Jul 2020 07:13:46 -0700 (PDT)
Received: by with SMTP id d17so39707658ljl.3 for <>; Wed, 08 Jul 2020 07:13:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TU4UMVr0Ynz0M30ckEzLTexnFvpQNqdYCpSNEglwxE0=; b=uc0AJ1g0w80aBl4oy7X7TsmqFEPmJsYCnwjKw/jZwXVPPXxPmavX5UC2hH5HNzv8Sp hQWua8bsm1FulKAIltP+hHbJbUrGpCgO3Ro8s4hDbgY6MdjGnzOx8+Pgmticvv7j99tA XYEaQF1/7VXZjcHBHXxhVLC2pW6coRQs5kkzb32VWwem+tAmbvOHKUbIR11IiovUm1Uv e4auDqzC4LJseuaYpmk4gpkkpfKoxGwqr9G7TXVoD+njVsM2nN3o6Qsg94tYPek9hdIb DfxL0zvvqO5sT2BEOFNcyjcn5Hsa6WB34wtJFydZvcXY4KMjBfj2eiBF9Fi+jS1WTBh7 S+Tg==
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=TU4UMVr0Ynz0M30ckEzLTexnFvpQNqdYCpSNEglwxE0=; b=Y1DfOCVAzE8H+1SlGeDEL/bydZhfCow9QdmUbmTWqMaxRV1Bm82a5sIbJkXEmeuvWO Jvb7/DjMk3rHHUghIXLrjfWcpIkQWgfpN3yDsm9sVQSyL9CU4iaj/3exujX6K9JJs14T 7Xi9IGTM9wgDO2jGDluIsmnpwej/uS+z5NS66jk3KgQHKXLcj/qLSM1djnNgQjnaSbtp USIE3zqYbEyr20c+mudmvg2i+hd4knAt9kwlmuQOPW1x1O8flRkfoISxLZ+Y+gf2PlV4 VWFiVN/5mU0MqhpFjIC2DDSDzumuBuk99/S2oxjoJ4sdO+dbboGf+C+CZyCcDgEcIJYN 9gjw==
X-Gm-Message-State: AOAM531KXHC4tdxuoSrvl3VxiFhbN543z/V9kL7uQ5/Y+90CjlpJhOHx JDieQGqyMnwNHR1qJz+up+NH3ydRzg41pLiwLJ65FyRUu1A=
X-Google-Smtp-Source: ABdhPJwn8sfvSaO6o9dMXo+wureQu0oSo3VwuyHv0vC2sYmxsb+3DRRPmMzGXqn4iFC8DIr+xv7i4KtWek+AQUdTQWs=
X-Received: by 2002:a2e:81c4:: with SMTP id s4mr31638206ljg.284.1594217624597; Wed, 08 Jul 2020 07:13:44 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Victor Vasiliev <>
Date: Wed, 08 Jul 2020 10:13:33 -0400
Message-ID: <>
To: Martin Thomson <>
Cc: "" <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="00000000000035fcd205a9eeb739"
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: Wed, 08 Jul 2020 14:14:07 -0000

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.

It's both about solving the "lack of 0.5-RTT send capability" problem, and
about making the client aware that it will in fact get the settings in
0.5-RTT without having to risk waiting for an entire RTT.  I don't think
you can avoid putting a "I will correctly send and receive 0.5-RTT data"
signal into any location other than the TLS handshake, so this is less of a
question of *should*, and more of *how*.

For what it's worth, I don't think we should define a new ALPN token for
that; using ALPN tokens for flags will eventually lead to combinatorial
explosion (e.g. "if we define h2_half_rtt, we have to define h2c_half_rtt",
etc), and can also lead to some really unpleasant situations with Alt-Svc.

Also, as far as I am aware, SETTINGS are currently not carried over for
HTTP/2 0-RTT in any form, meaning that it's currently impossible to, for
example, send a WebSocket CONNECT request in HTTP/2 0-RTT.  The proposed
draft fixes that.

> 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

This probably works for 1-RTT, but I am not quite sure it would work with
0-RTT as currently defined in HTTP/3.

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

HTTP/3 approach to 0-RTT settings is based around the idea that things work
just fine with default settings (which is true if you don't have extensions
you care about), whereas ALPS aims to provide "actual settings are always
there" guarantee.  If you define extensions that require blocking on
settings, then not remembering settings makes 0-RTT useless anyways, so
this is kind of moot.  That said, we could add an "upgrade to compatible
settings" mechanism similar to QUIC if people believe it's useful.

Also, from what I recall, the approach we chose for HTTP/3 was partially
motivated by the ordering ambiguity between SETTINGS and NewSessionTicket,
which the proposed draft removes.

> 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