Re: [TLS] Application-Layer Protocol Settings

David Benjamin <> Tue, 07 July 2020 21:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD4CD3A0ABC for <>; Tue, 7 Jul 2020 14:17:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.25
X-Spam-Status: No, score=-9.25 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lTUCh2md43mw for <>; Tue, 7 Jul 2020 14:17:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D30933A0ABB for <>; Tue, 7 Jul 2020 14:17:31 -0700 (PDT)
Received: by with SMTP id d4so20586269pgk.4 for <>; Tue, 07 Jul 2020 14:17:31 -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=oC7Mw/WeHX9FbK2yOqczRh/7oUjWGiOgZfqYecX+I1U=; b=OzUmOe4RNXPlO58GZ2Ts5gokYpCX9bFPyEZZR9XD2XtPYbCuh4fDhNneATlkcQ9pKr fuql4N565I032G8TlcSZe/cYl73XQ+8udU9u5m0gbq+UHLi63v4e+aPATGn3N0GKWoCK EUE37V6a+Gc7bhfpdYQM1Gy3owTEY1ZRllsfg=
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=oC7Mw/WeHX9FbK2yOqczRh/7oUjWGiOgZfqYecX+I1U=; b=i0RzpmKD5BD5SGZO19JY4rdbB/zk49gkiv+kyCpHJYMQYpnkXPMt2c2yUDQ6N3XtvX 7RUQA6P2BbhQzavaTfxuKK50l4ylzqkYEIMLojaM/sTuK2SMDqWjUwmCV9z8b8TpkUlw jj1BLxRS0qEeb2Co/KNPK0vFTLphVW/pTdWMDKn0coKWGaIZD9cZRWxZjwxOAgmMJQtQ dkE8puUB8mGkXPtdyC8s0TOlVVOActiC3BqffinyF8ORqmqdcHTVVslyfCfIVO3Nn55U 1tMpv3GShOLre6rBBCnM7DotxJHrnu83HGiVHdUPczSp4qjCTl226Tlw8gH2oCPiZYq6 y7Eg==
X-Gm-Message-State: AOAM531NR2gL20W/oHt+rVrswMHxwmqskb8fYT7DBBrqiKss2VZZhdTA /S0I/kHgo1QZ4g+JiKExbirMeidlYDp62XI5MTNz
X-Google-Smtp-Source: ABdhPJyVCh8ClTndi3AmH3a3YUGMJ4Dhzhfav9PLhFsNkEw7Z4WXgPLsha0HEf+sQMhVpKf0IzD5ptlsq34j3Umgxlo=
X-Received: by 2002:a63:8f51:: with SMTP id r17mr41325326pgn.124.1594156651031; Tue, 07 Jul 2020 14:17:31 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Tue, 07 Jul 2020 17:17:14 -0400
Message-ID: <>
To: Ben Schwartz <>
Cc: Victor Vasiliev <>, "" <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000e7064105a9e08464"
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 21:17:34 -0000

On Tue, Jul 7, 2020 at 4:38 PM Ben Schwartz <> wrote:

> On Tue, Jul 7, 2020 at 3:14 PM David Benjamin <>
> wrote:
>> Any solution here involves a TLS change, even for servers which currently
>> send half-RTT settings. ...
> I think a new ALPN protocol ID
> ("h2-but-with-settings-from-the-server-asap-for-real") would suffice.

That doesn't suffice. Please see my reply to Martin. This would be one
possible spelling of the indicator, but it would not provide the other
components necessary for half-RTT data to work.

> It’s also not the case that non-uniform backends must disable 0-RTT. That
>> is what 0-RTT rejection logic is for. ...
> I would be impressed if there is any TLS load balancer architecture that
> supports 0-RTT rejection by the backend.  This would require an interesting
> new metadata layer, quite different from the usual "decrypt and forward"
> approach.  (Of course, I assume that most load balancers simply won't
> implement 0-RTT at all.)

HTTP/3 0-RTT *already* requires such an interaction. In fact, it requires
an even more complex version than ALPS. The link was lost in the quoted
reply, so I'll include it again:

This is fundamentally unavoidable if you want 0-RTT to be able to use
negotiated parameters. Any negotiated parameter available to 0-RTT *must* be
available predictively. Because it is predictive, mispredictions may occur.

RFC8470 likewise contains recommendations which also require more than a
"decrypt and forward" approach.

> The simpler that TLS/HTTP interaction, the looser the coupling we can
>> manage, and checking opaque bytes for equality is the simplest possible
>> option here.
> I'm not sure what equality check you're proposing; I don't see it in the
> draft.

It's right here:

>   For application protocols that support 0-RTT data, both the client
>   and the server have to remember the settings provided by the both
>   sides during the original connection.  If the client sends 0-RTT data
>   and the server accepts it, the ALPS values SHALL be the same values
>   as were during the original connection.  In all other cases
>   (including session resumption that does not result in server
>   accepting early data), new ALPS values SHALL be negotiated.
>   If the client wishes to send different client settings for the 0-RTT
>   session, it MUST NOT offer 0-RTT.  Conversely, if the server would
>   send different server settings, it MUST reject 0-RTT.  Note that the
>   ALPN itself is similarly required to match the one in the original
>   connection, thus the settings only need to be remembered or checked
>   for a single application protocol.

> However, I agree with your conclusion: if the TLS server manages the
> settings-state, it can easily invalidate resumption across a settings
> change.
> Ultimately, I think I'm saying something obvious: if the TLS server
> represents multiple backends without distinction, it can't represent a
> property that those backends do not share.  This is true of ALPN, and would
> be true of ALPS too.  This is fine; the ALPS just has to represent the
> intersection of backend capabilities.  All currently defined HTTP/2
> Settings appear to support intersection in a reasonable way, although I'm
> not sure this is guaranteed in general.  However, SETTINGS at 0.5-RTT would
> not have this problem; heterogeneous backends could each report their own

I don't think this follows. ALPS and half-RTT data happen at the same
round-trip. If the frontend is able to forward half-RTT data, it has
clearly decided on which backend to use by the time it's assembling the
ServerHello flight. It can as easily pick a backend-specific ALPS value as
it can pick backend-specific half-RTT data.

Beyond that, it's a question of what exactly your frontend/backend split
looks like. I gather you're worried about a deployment scenario where your
frontend is a TLS terminator, which has a boring pipe to the HTTP backend,
without any out-of-band signaling. (As opposed to having an HTTP frontend.)
In that case, the argument is that, since half-RTT data is just bytes, that
can be transparently forwarded over the pipe, whereas an ALPS signal
wouldn't. Is that right?

It's unlikely half-RTT data would work for that scenario. The frontend most
likely waits for the handshake to actually finish, before enabling the
pipe. Indeed, the security properties of the half-RTT point are kind of
subtle (particularly with client certs). Forwarding data then without
appropriate signaling is dangerous.

Such a frontend/backend split would also likely be unable to manage the
recommendations in RFC8470, the remembered settings vs. 0-RTT interactions,
the guarantee of half-RTT data being sent early enough, or the delimiting
information necessary to make a half-RTT settings work. For that matter, it
already needs some out-of-band signaling to communicate the ALPN protocol.

ALPS probably even helps this kind of deployment, by at least making it
possible to statically configure the settings. Static configuration risks
the footguns you mention below, but when all you've got is a boring pipe,
there aren't many options.

This is not an unreasonable design choice given the other constraints
> you've mentioned, but it is a limitation, and potentially a footgun (e.g.
> if someone forgets to revert the ALPS config change before rolling back the
> HTTP server config change).

Again, this depends on where your frontend/backend split is, and what is
the communication between them. Note also that this hypothetical deployment
model already has a similar footgun around ALPN.