Re: [TLS] Application-Layer Protocol Settings

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

Return-Path: <bemasc@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD763A090D for <tls@ietfa.amsl.com>; Mon, 6 Jul 2020 19:23:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
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: 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 sZy0PXfEexo2 for <tls@ietfa.amsl.com>; Mon, 6 Jul 2020 19:23:35 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 839FB3A090B for <TLS@ietf.org>; Mon, 6 Jul 2020 19:23:35 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id k6so43498880wrn.3 for <TLS@ietf.org>; Mon, 06 Jul 2020 19:23:35 -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=9av0oJrmc4cUjawlYfgEm/4oTcqd3uVo09atCi+cC/c=; b=PFUsfeIIaUoVcDnube/gwJWH9ACiu4kOOzvXBglkazm5xWHxELEKP4GpPWKuewOg/W /NPPpDRoxOuMRxZ27CP0NhveutB2bF+IRgnCkEV0ps2SuK3NknLm4DMdbyM+mrqqjOaK SgZwruuVCNqOMlpjUSmIXX6NPzgWe5y31bmcr0n+gPTgGC1r37Hxefc4A4EJzy8bOwku 3mnpDXmYyEBOnO2mLGWhiMAaejozpgj7xfsOeZV6AtBUVqVsHfnMyMIdjGtbIefvAOYL Lh7G7Avm839idCOLx2+mNeRV3WSwoSpINOjmllSlJwv4MJ1cJXk5WeHpp1F0ZjgB8LLO YZNA==
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=9av0oJrmc4cUjawlYfgEm/4oTcqd3uVo09atCi+cC/c=; b=cNwsHomfvIGPf8NFKIw6Rhb9FsS9O4GWmmAYMBQhMWYkVtncUdC1qAhaikdkZusCUF 8Yp16p3ytZ/BXmw+q8whBLharQQMYzqO4lmRnMAwTmBAVF1SeWjS8IuuIpIWGnR1+DYy 7otKa+mFtfIbWdS6YMPBrN6XiJydqfLqEsxGAiPffyxFglGel4672wYl4KGiFQh1/UJP 9G67++6UnC7M/D75OLEMRbcIEVmi/qS8bdAh73BRijp+cSa5NIPf8VDxSwpJjXYxpn+8 o6CsmFFH/h7z7dxYYtcZPpVm8GMYb3NzYZLJvhLgxWrAXzrrxughvWkusi3/xMuNRt0E xX0w==
X-Gm-Message-State: AOAM530qNp5IhftUwJNvMZ3QcuuNTiws1LoASPtj2t23GCC4vaYIyIFE ZLaYqe65oBg6vfzqhoyvU6sPGxA4bzDBuJbZy+M5AA==
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="00000000000095000b05a9d0ad3b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ENOY9AIjrHVIYk6cQsFkwXu4j4E>
Subject: Re: [TLS] Application-Layer Protocol Settings
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jul 2020 02:23:37 -0000

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
>