Re: [TLS] Application-Layer Protocol Settings

Victor Vasiliev <vasilvv@google.com> Wed, 08 July 2020 14:16 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 7603F3A0C27 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 8 Jul 2020 07:16:42 -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=unavailable 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 9KC55QDy-ncJ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 8 Jul 2020 07:16: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 01EDE3A0C32 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 8 Jul 2020 07:16: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 1jtApj-0008JC-FC for ietf-http-wg-dist@listhub.w3.org; Wed, 08 Jul 2020 14:13:59 +0000
Resent-Date: Wed, 08 Jul 2020 14:13:59 +0000
Resent-Message-Id: <E1jtApj-0008JC-FC@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 <vasilvv@google.com>) id 1jtApi-0008IZ-GC for ietf-http-wg@listhub.w3.org; Wed, 08 Jul 2020 14:13:58 +0000
Received: from mail-lj1-x230.google.com ([2a00:1450:4864:20::230]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <vasilvv@google.com>) id 1jtApg-0001yl-Dc for ietf-http-wg@w3.org; Wed, 08 Jul 2020 14:13:58 +0000
Received: by mail-lj1-x230.google.com with SMTP id q7so41184710ljm.1 for <ietf-http-wg@w3.org>; Wed, 08 Jul 2020 07:13:55 -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=TU4UMVr0Ynz0M30ckEzLTexnFvpQNqdYCpSNEglwxE0=; b=uc0AJ1g0w80aBl4oy7X7TsmqFEPmJsYCnwjKw/jZwXVPPXxPmavX5UC2hH5HNzv8Sp hQWua8bsm1FulKAIltP+hHbJbUrGpCgO3Ro8s4hDbgY6MdjGnzOx8+Pgmticvv7j99tA XYEaQF1/7VXZjcHBHXxhVLC2pW6coRQs5kkzb32VWwem+tAmbvOHKUbIR11IiovUm1Uv e4auDqzC4LJseuaYpmk4gpkkpfKoxGwqr9G7TXVoD+njVsM2nN3o6Qsg94tYPek9hdIb DfxL0zvvqO5sT2BEOFNcyjcn5Hsa6WB34wtJFydZvcXY4KMjBfj2eiBF9Fi+jS1WTBh7 S+Tg==
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=TU4UMVr0Ynz0M30ckEzLTexnFvpQNqdYCpSNEglwxE0=; b=jhXVNNOPtCKUfib0BL0NAGU1iISA8ASIxYTdvMa5sZLkp1ctFAzqrBfpaIzztijs3R 5lYkU2gp3tqFnlBLQOGOgxmn+ZgWpSgSek4krDd2hhA/dMcBzwMvtBHUcCap3LOnUIIw eaVK5W5oS0C01p0FKkiXY0Y1go93uXMfKAWLjQgfgGaR70JnWjczKjN3OhzuorFq90/m 9LGhDWDJqdATzWFuK6Lw6Ku80rrv8DgEQb+u267w246eTwORTOPEOIPsjOORGG6HZAoa 72k70CG2fJ0LeLuFbSaqBm38YA2cQEqIhf19fM6MBFAzMmZrszlkPijcQ7iIi9ss5OWa cOWg==
X-Gm-Message-State: AOAM530CW1TO0n8SjJeFUHUFzHmTic2q0xVqNuXeTrtk6lRgSTrBtNxf TqQM5nATwiqGqoOiKKUacPKaq5QwDYO/meGvtqd7Ew==
X-Google-Smtp-Source: ABdhPJwn8sfvSaO6o9dMXo+wureQu0oSo3VwuyHv0vC2sYmxsb+3DRRPmMzGXqn4iFC8DIr+xv7i4KtWek+AQUdTQWs=
X-Received: by 2002:a2e:81c4:: with SMTP id s4mr31638206ljg.284.1594217624597; Wed, 08 Jul 2020 07:13:44 -0700 (PDT)
MIME-Version: 1.0
References: <CAAZdMaf2dKab0dJU8MLZc9JzEcVSvf8s9kgeZFo3tmsRtx2sNQ@mail.gmail.com> <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com>
In-Reply-To: <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com>
From: Victor Vasiliev <vasilvv@google.com>
Date: Wed, 8 Jul 2020 10:13:33 -0400
Message-ID: <CAAZdMacsDdcZCcS1yLSQwO3rbhnh8AVkgZHrt+A+KDKKaYWO7g@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: "tls@ietf.org" <tls@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="00000000000035fcd205a9eeb739"
Received-SPF: pass client-ip=2a00:1450:4864:20::230; envelope-from=vasilvv@google.com; helo=mail-lj1-x230.google.com
X-W3C-Hub-Spam-Status: No, score=-24.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_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1jtApg-0001yl-Dc abcca7a0962aa1e6a7f0a2413aa66254
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [TLS] Application-Layer Protocol Settings
Archived-At: <https://www.w3.org/mid/CAAZdMacsDdcZCcS1yLSQwO3rbhnh8AVkgZHrt+A+KDKKaYWO7g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37857
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 1:10 AM Martin Thomson <mt@lowentropy.net> wrote:

> Hi Victor,
>
> For HTTP/2, this is essentially a noop, as endpoints are required to send
> SETTINGS immediately.  Whether these bytes appear before Finished or not
> only affects endpoints that aren't inclined to wait for SETTINGS.  This is
> somewhat complicated by the way that TLS 1.2 and TLS 1.3 differ, but if we
> assume TLS 1.3 here, any uncertainty is easily avoided.
>
> The main justification here appears to be based on the lack of 0.5-RTT
> send capability at some servers.  I don't know how to assess whether the
> cost of greater integration with the TLS stack is preferable to fixing the
> 0.5-RTT send problem.
>

It's both about solving the "lack of 0.5-RTT send capability" problem, and
about making the client aware that it will in fact get the settings in
0.5-RTT without having to risk waiting for an entire RTT.  I don't think
you can avoid putting a "I will correctly send and receive 0.5-RTT data"
signal into any location other than the TLS handshake, so this is less of a
question of *should*, and more of *how*.

For what it's worth, I don't think we should define a new ALPN token for
that; using ALPN tokens for flags will eventually lead to combinatorial
explosion (e.g. "if we define h2_half_rtt, we have to define h2c_half_rtt",
etc), and can also lead to some really unpleasant situations with Alt-Svc.

Also, as far as I am aware, SETTINGS are currently not carried over for
HTTP/2 0-RTT in any form, meaning that it's currently impossible to, for
example, send a WebSocket CONNECT request in HTTP/2 0-RTT.  The proposed
draft fixes that.


> For HTTP/3, this has some incremental effect beyond that.  In effect, this
> deliberately introduces head-of-line blocking for settings.  You can
> already do that in HTTP/3 if you are not prepared to deal with settings
> being in an ambiguous state.  There's a little more determinism here in
> terms of where you look for the data that unblocks progress, but with
> retransmissions, this is not a difference worth worrying about.
>
> What this head-of-line blocking might allow is the development of new
> extensions that are unable to deal with uncertainty regarding SETTINGS.
> But isn't it also possible to address that problem by saying "if you
> implement extension X, then you MUST NOT send requests prior to receiving
> SETTINGS?"
>

This probably works for 1-RTT, but I am not quite sure it would work with
0-RTT as currently defined in HTTP/3.


> In QUIC, we decided that having the server repeat its configuration after
> 0-RTT was preferable to remembering it.  This was after a non-trivial
> number of questions about that part of the specification.  You seem to have
> taken the opposite approach.  Is that deliberate?  If so, why?
>

HTTP/3 approach to 0-RTT settings is based around the idea that things work
just fine with default settings (which is true if you don't have extensions
you care about), whereas ALPS aims to provide "actual settings are always
there" guarantee.  If you define extensions that require blocking on
settings, then not remembering settings makes 0-RTT useless anyways, so
this is kind of moot.  That said, we could add an "upgrade to compatible
settings" mechanism similar to QUIC if people believe it's useful.

Also, from what I recall, the approach we chose for HTTP/3 was partially
motivated by the ordering ambiguity between SETTINGS and NewSessionTicket,
which the proposed draft removes.


>
> On Tue, Jul 7, 2020, at 05:12, Victor Vasiliev 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
> >
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>