Re: [TLS] Application-Layer Protocol Settings

Ben Schwartz <bemasc@google.com> Tue, 07 July 2020 02:26 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 E55BA3A090D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 6 Jul 2020 19:26:41 -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 S1sBKXucuk77 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 6 Jul 2020 19:26:40 -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 CD75D3A090B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 6 Jul 2020 19:26:39 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jsdH0-0008Gb-9U for ietf-http-wg-dist@listhub.w3.org; Tue, 07 Jul 2020 02:23:54 +0000
Resent-Date: Tue, 07 Jul 2020 02:23:54 +0000
Resent-Message-Id: <E1jsdH0-0008Gb-9U@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <bemasc@google.com>) id 1jsdGy-0008Fa-QD for ietf-http-wg@listhub.w3.org; Tue, 07 Jul 2020 02:23:52 +0000
Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <bemasc@google.com>) id 1jsdGs-0000iI-1w for ietf-http-wg@w3.org; Tue, 07 Jul 2020 02:23:52 +0000
Received: by mail-wr1-x433.google.com with SMTP id o11so43511492wrv.9 for <ietf-http-wg@w3.org>; Mon, 06 Jul 2020 19:23:44 -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=4swNfBayg+6Fd6/6k1qRiaAKavrB+95sioP6rsyiFoU=; b=SA4HI3+r4aRI6rGJzgccZwDl9khudfuA526DHCxHVzBCqMhtmYW485VWVkO3wGgP7i hJwD2LcH0KYTJbGTgf7xFlV8y2BTI3HR8AaQu2TAAqQkUQVJ3yq1CDTWUq8A9kRdfHNw 8SV2mWHEo/3qfxPWesDYU/lPk8oyxZwus5UY6IZM9ScOzzu8BVMmt52139XatuxDn9LS 0mCVaFx/YUhmPTw2KD4TdTdglZcOG3njvlDNhtGzP8F6LshiRK2weL97kcQaeYMZVnwe EnApKoRQfd79lNYyEGZ19QGi29ks9D5uBy5UhzNwuvkZUt0HanB/XOAQiNvq1/H/Qk6e O4dg==
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=4swNfBayg+6Fd6/6k1qRiaAKavrB+95sioP6rsyiFoU=; b=MP+Zu8h4cXIIJ9DWMMMOyOAmEANAaD5EIAE2AQvRWIkK20ZwJGyk/DjqrAV65mLEYb MturSljhUjKUdrBMdXQ/S3UUsh/61eh/lM0l9BPqAg2GBfkBD0EbB2NZ9JvpvdNvGH1S T+lk3jVHFbzELYiMKww6APjX9G/cNfmW5MbAeDWos4e9J1bIJN6mzG631SjEUU52XHEe QOt1ETLRMCkJ85ed0+pxfsaBQrHhcjd6HgVi25aOGOrxBiYSxQFGFuKCz0C3RoRKOADw XNvUYq2Rabo6LXdaNK3IU/I41O4nUutMKOQuvHjaXcfWwz4QayOiLPmKhqQs1UNzPTdo 8DVw==
X-Gm-Message-State: AOAM532ShRBm5d0U508VV8W2qOQS+Rwqx3G1DV8Jahj3qN7U1skOQP9v i1SZycBbaQtlyLc4JQnwP/DHXH9+4KGgUiTJ1GefG8CWGrVnfA==
X-Google-Smtp-Source: ABdhPJwDp9gTlCZa01259gjmviGLUKHYujD9zVHNxa7Bj1cnxJMyuje387OkL9ELtWNTMDAfe09hEVSuqSxUQCrU0WQ=
X-Received: by 2002:adf:e850:: with SMTP id d16mr53671621wrn.426.1594088613663; Mon, 06 Jul 2020 19:23:33 -0700 (PDT)
MIME-Version: 1.0
References: <CAAZdMaf2dKab0dJU8MLZc9JzEcVSvf8s9kgeZFo3tmsRtx2sNQ@mail.gmail.com>
In-Reply-To: <CAAZdMaf2dKab0dJU8MLZc9JzEcVSvf8s9kgeZFo3tmsRtx2sNQ@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 6 Jul 2020 22:23:22 -0400
Message-ID: <CAHbrMsDLKdvapbg8EStXhqdyt=U9GnVgu3s2F1hDhQaOQKB3dA@mail.gmail.com>
To: Victor Vasiliev <vasilvv=40google.com@dmarc.ietf.org>
Cc: "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="0000000000009500fd05a9d0ad40"
Received-SPF: pass client-ip=2a00:1450:4864:20::433; envelope-from=bemasc@google.com; helo=mail-wr1-x433.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: titan.w3.org 1jsdGs-0000iI-1w 7b4bd1b49f3c59bd2d36161e479e6b11
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [TLS] Application-Layer Protocol Settings
Archived-At: <https://www.w3.org/mid/CAHbrMsDLKdvapbg8EStXhqdyt=U9GnVgu3s2F1hDhQaOQKB3dA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37845
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>

Thanks for this draft.  I believe this is an important problem for HTTP
extensibility, and I'm glad to see work on a solution.

It occurs to me that this solution requires pretty tight integration
between the TLS termination and the HTTP backend.  Some TLS load balancers
already support ALPN, but they would have to be extended to support ALPS,
and I would worry about the potential for skew between the TLS terminator's
claimed settings and the backend's actual settings.

The draft says
   1.  While the server is technically capable of sending configuration
       to the peer as soon as it sends its Finished message, most TLS
       implementations do not allow any application data to be sent
       until the Finished message is received from the client.

Fixing this might require a change to some TLS implementations, but the
change to implement ALPS also seems significant.

The proposed 0-RTT interaction also seems like it would create a
significant risk of skew when a load balancer is in use, if the backend
settings can change.  Deployments that can't guarantee uniform backends
would have to disable 0-RTT (an unfortunate sacrifice for a feature that
saves 1 RTT!).

For load balancers, or any other situation where TLS and HTTP are loosely
coupled, sending SETTINGS at 0.5-RTT would seem like a much simpler
solution.  I know the draft mentions a few cases where this doesn't work
well, but perhaps there's a middle ground of some sort.  For example:

* If supporting generic 0.5-RTT forwarding is hard, TLS server
implementations could offer a configuration to send an arbitrary fixed
buffer at 0.5-RTT (depending on ALPN).  No standards change is required.
* The application protocol (here HTTP) could indicate what state is
guaranteed to persist across session resumption.  Although the preserved
state here (SETTINGS) is ~static, in general this could include dynamic
session state too.  This would move the change to HTTP, instead of TLS.

On Mon, Jul 6, 2020 at 3:13 PM Victor Vasiliev <vasilvv=
40google.com@dmarc.ietf.org> 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:
>
>    - https://github.com/quicwg/base-drafts/issues/3086
>    - https://github.com/quicwg/base-drafts/issues/3622
>    - https://github.com/WICG/client-hints-infrastructure/pull/30
>
> I wrote up a draft for the TLS extension that would solve this problem:
> https://tools.ietf.org/html/draft-vvv-tls-alps-00
>
> I also wrote up a draft that explains how to use that extension with HTTP,
> and defines some settings (the ones discussed here
> <https://github.com/quicwg/base-drafts/issues/3622>) that would not be
> possible without it: https://tools.ietf.org/html/draft-vvv-httpbis-alps-00
>
> I would appreciate feedback on those drafts.
>
> Thanks,
>   Victor.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>