Re: [TLS] Application-Layer Protocol Settings

Ben Schwartz <bemasc@google.com> Tue, 07 July 2020 20:41 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EED3A0A78 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 7 Jul 2020 13:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTjhEQ5vAjJa for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 7 Jul 2020 13:41:12 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8203A0A73 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 7 Jul 2020 13:41:11 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jsuMB-0001L4-RQ for ietf-http-wg-dist@listhub.w3.org; Tue, 07 Jul 2020 20:38:23 +0000
Resent-Date: Tue, 07 Jul 2020 20:38:23 +0000
Resent-Message-Id: <E1jsuMB-0001L4-RQ@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <bemasc@google.com>) id 1jsuMA-0001KI-Nj for ietf-http-wg@listhub.w3.org; Tue, 07 Jul 2020 20:38:22 +0000
Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <bemasc@google.com>) id 1jsuM8-0003cF-SR for ietf-http-wg@w3.org; Tue, 07 Jul 2020 20:38:22 +0000
Received: by mail-wm1-x334.google.com with SMTP id a6so2490062wmm.0 for <ietf-http-wg@w3.org>; Tue, 07 Jul 2020 13:38:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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; d=1e100.net; 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: <CAAZdMaf2dKab0dJU8MLZc9JzEcVSvf8s9kgeZFo3tmsRtx2sNQ@mail.gmail.com> <CAHbrMsDLKdvapbg8EStXhqdyt=U9GnVgu3s2F1hDhQaOQKB3dA@mail.gmail.com> <CAF8qwaA7eLJcAuV+kPxLOO-hpjFO9XBJAMhMiZCoawaT+aKC3Q@mail.gmail.com>
In-Reply-To: <CAF8qwaA7eLJcAuV+kPxLOO-hpjFO9XBJAMhMiZCoawaT+aKC3Q@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 7 Jul 2020 16:37:57 -0400
Message-ID: <CAHbrMsDpz72VtBhgwcueZ0wK1EOg+Jo57Fupt7vy8b+NOY57Uw@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Cc: Victor Vasiliev <vasilvv@google.com>, "tls@ietf.org" <TLS@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000270a2205a9dff87d"
Received-SPF: pass client-ip=2a00:1450:4864:20::334; envelope-from=bemasc@google.com; helo=mail-wm1-x334.google.com
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: mimas.w3.org 1jsuM8-0003cF-SR a6122a427dcbb9e9212cc35ed8895bc9
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [TLS] Application-Layer Protocol Settings
Archived-At: <https://www.w3.org/mid/CAHbrMsDpz72VtBhgwcueZ0wK1EOg+Jo57Fupt7vy8b+NOY57Uw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37851
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Tue, Jul 7, 2020 at 3:14 PM David Benjamin <davidben@chromium.org> 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
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
SETTINGS.

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