Re: [TLS] Application-Layer Protocol Settings

Ben Schwartz <> Tue, 07 July 2020 20:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E9EED3A0A78 for <>; Tue, 7 Jul 2020 13:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Status: No, score=-10.249 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, 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, USER_IN_DEF_DKIM_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 XTjhEQ5vAjJa for <>; Tue, 7 Jul 2020 13:41:12 -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 2F8203A0A73 for <>; Tue, 7 Jul 2020 13:41:11 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jsuMB-0001L4-RQ for; Tue, 07 Jul 2020 20:38:23 +0000
Resent-Date: Tue, 07 Jul 2020 20:38:23 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jsuMA-0001KI-Nj for; Tue, 07 Jul 2020 20:38:22 +0000
Received: from ([2a00:1450:4864:20::334]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jsuM8-0003cF-SR for; Tue, 07 Jul 2020 20:38:22 +0000
Received: by with SMTP id a6so2490062wmm.0 for <>; Tue, 07 Jul 2020 13:38:20 -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=/zviK/+u8p0M3CE+1xVXVrkAJrRf6SS6ULt5sZtLIkY=; b=Idq8Q6N3CbJksf0VV2hrI17S2O+2QzzRLYuLkxXTAmMrcNQ1QJc76aI3/hIL1vOKcg SI8Cgglk2o7m37UNaIZWsFRHBbpXNKPhfIUO6MjNswI/l9D5hYX5R6Qy0dl3cs4gQv0c GRDrGafeYmKWzYVL8t/p/nH1EYFnD+U+NL27YnfK0ODXFKMDObPZraaKcmjgR+VoSxM/ oK7EZ1+XZtD9LK6RQcWDpyB2RpQdGjPVnIBC/VIwOhkqgQVeQC9NUmxIMa6UioxqU4jz wWH8Y8Y/89fp9lxoNtOd4zr4cRKvz43LsoxZycMNWn1mW4b5E3W3Go2Lqq9tR30qTyol Gsiw==
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=/zviK/+u8p0M3CE+1xVXVrkAJrRf6SS6ULt5sZtLIkY=; b=az15YzGdvI0nbWD93pI/P4ZOBzjPz5I5GWWGJRxmvLka1HMUDJ+Y43BOiLDf5QSNUX 1SiZxqVxQ+7ycILdwpiV45y67wsNUZp268cR8PrsnvzRCqgvSf/BycXyxAB//YRyxPJB 5+18SCSpgY9HBDRH7zPcQmHSee0X43ZcMpZFnc43CM3gh4166FFTvQFy6qzmpme1i2w3 4Jcgf6Nhf678+PMmIPBYWNCwAS95625qpyH9srx7lZRCHdDV6ckhwAI8mDJvLzn8d8Pi ImakPRCka/DChRhcr9U0C7afv9jMjfXXHHRpYoc/9jAA7dS3xR8ETDyA6kHcvdgWj8Kf ePow==
X-Gm-Message-State: AOAM531Qn9pst3gY7iLEcRRpmMQPnozxsuhkxr2dqv150Hh03R06aQlc pPT6hcwciF4Xg1s1cncLWaFvkYmo6YCiT67ynyLgFA==
X-Google-Smtp-Source: ABdhPJwfxEbztzGAl0jDdICN6Dw2NxJCzyQ5j+KBqASICm+Teo/owbdg3OS1h2yHC5mF6UZn7zhkb91S3aBTiZ/T5vA=
X-Received: by 2002:a7b:c3c7:: with SMTP id t7mr5589914wmj.97.1594154289236; Tue, 07 Jul 2020 13:38:09 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Tue, 7 Jul 2020 16:37:57 -0400
Message-ID: <>
To: David Benjamin <>
Cc: Victor Vasiliev <>, "" <>, HTTP Working Group <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000270a2205a9dff87d"
Received-SPF: pass client-ip=2a00:1450:4864:20::334;;
X-W3C-Hub-Spam-Status: No, score=-20.6
X-W3C-Hub-Spam-Report: 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1jsuM8-0003cF-SR a6122a427dcbb9e9212cc35ed8895bc9
Subject: Re: [TLS] Application-Layer Protocol Settings
Archived-At: <>
X-Mailing-List: <> archive/latest/37851
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.

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

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.  However, I agree with your conclusion: if the TLS server manages
the settings-state, it can easily invalidate resumption across a settings

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

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