Re: [TLS] Application-Layer Protocol Settings

David Benjamin <davidben@chromium.org> Tue, 07 July 2020 21:20 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 4CFA03A0B24 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 7 Jul 2020 14:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Level:
X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 iebhmxPWqORn for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 7 Jul 2020 14:20:22 -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 6784A3A0B26 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 7 Jul 2020 14:20:21 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jsuyI-0006gv-BP for ietf-http-wg-dist@listhub.w3.org; Tue, 07 Jul 2020 21:17:46 +0000
Resent-Date: Tue, 07 Jul 2020 21:17:46 +0000
Resent-Message-Id: <E1jsuyI-0006gv-BP@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 <davidben@google.com>) id 1jsuyG-0006g4-Qe for ietf-http-wg@listhub.w3.org; Tue, 07 Jul 2020 21:17:44 +0000
Received: from mail-pg1-x52a.google.com ([2607:f8b0:4864:20::52a]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <davidben@google.com>) id 1jsuyE-0004rY-Iy for ietf-http-wg@w3.org; Tue, 07 Jul 2020 21:17:44 +0000
Received: by mail-pg1-x52a.google.com with SMTP id j19so13723686pgm.11 for <ietf-http-wg@w3.org>; Tue, 07 Jul 2020 14:17:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oC7Mw/WeHX9FbK2yOqczRh/7oUjWGiOgZfqYecX+I1U=; b=OzUmOe4RNXPlO58GZ2Ts5gokYpCX9bFPyEZZR9XD2XtPYbCuh4fDhNneATlkcQ9pKr fuql4N565I032G8TlcSZe/cYl73XQ+8udU9u5m0gbq+UHLi63v4e+aPATGn3N0GKWoCK EUE37V6a+Gc7bhfpdYQM1Gy3owTEY1ZRllsfg=
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=oC7Mw/WeHX9FbK2yOqczRh/7oUjWGiOgZfqYecX+I1U=; b=HyFOmCJvbRh6h4Wmpq7D9DmIKLRHS8vnqg6wgxV5Iax4nqNrWSKzxFKUciZJkgtqlu ChiUTaV4nWknAW4gd7ZQUvQShtgWyFkeFpdVhE4g5UQRhhxsWEE6MKusrTJQS2r5L+K0 mPgORxcq+DC5N0X8VLDrpY75k0xnXGRMmRL4VX4v+MwWeOe3Nwb6e4fxLMZ4hg1QCnCL qMXSjFn0Ikz1n9c7G+72MRFZr3dTvRKb3LoiPbVI8on2P/zIgRUIk2/cZJjewjFDaxyd s6u5K4tjrfsxbuNNh28B+RQjUP7t2Qm/QtM6xN3raIpgBbM1Qh0I8mE4Ne2g1OoQtD8s xyTw==
X-Gm-Message-State: AOAM531TEbmig8T++ASCU2ayrcX0b+B0m7WM79L/ehIRXQGdKfeo9Ugh 6fafNIB2vBI9H+ZD3FVpekpewhW0Xjd8H5Uues9q
X-Google-Smtp-Source: ABdhPJyVCh8ClTndi3AmH3a3YUGMJ4Dhzhfav9PLhFsNkEw7Z4WXgPLsha0HEf+sQMhVpKf0IzD5ptlsq34j3Umgxlo=
X-Received: by 2002:a63:8f51:: with SMTP id r17mr41325326pgn.124.1594156651031; Tue, 07 Jul 2020 14:17:31 -0700 (PDT)
MIME-Version: 1.0
References: <CAAZdMaf2dKab0dJU8MLZc9JzEcVSvf8s9kgeZFo3tmsRtx2sNQ@mail.gmail.com> <CAHbrMsDLKdvapbg8EStXhqdyt=U9GnVgu3s2F1hDhQaOQKB3dA@mail.gmail.com> <CAF8qwaA7eLJcAuV+kPxLOO-hpjFO9XBJAMhMiZCoawaT+aKC3Q@mail.gmail.com> <CAHbrMsDpz72VtBhgwcueZ0wK1EOg+Jo57Fupt7vy8b+NOY57Uw@mail.gmail.com>
In-Reply-To: <CAHbrMsDpz72VtBhgwcueZ0wK1EOg+Jo57Fupt7vy8b+NOY57Uw@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Tue, 7 Jul 2020 17:17:14 -0400
Message-ID: <CAF8qwaDh5aWbRdSqNi63H-GiTBznpeZuDsR_STPj8=SCaZ7b9w@mail.gmail.com>
To: Ben Schwartz <bemasc@google.com>
Cc: Victor Vasiliev <vasilvv@google.com>, "tls@ietf.org" <TLS@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000e7064105a9e08464"
Received-SPF: pass client-ip=2607:f8b0:4864:20::52a; envelope-from=davidben@google.com; helo=mail-pg1-x52a.google.com
X-W3C-Hub-Spam-Status: No, score=-11.3
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_HIGH=-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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1jsuyE-0004rY-Iy bc53aa59861e92b26a12345481a96767
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [TLS] Application-Layer Protocol Settings
Archived-At: <https://www.w3.org/mid/CAF8qwaDh5aWbRdSqNi63H-GiTBznpeZuDsR_STPj8=SCaZ7b9w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37852
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 4:38 PM Ben Schwartz <bemasc@google.com> wrote:

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

That doesn't suffice. Please see my reply to Martin. This would be one
possible spelling of the indicator, but it would not provide the other
components necessary for half-RTT data to work.


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

HTTP/3 0-RTT *already* requires such an interaction. In fact, it requires
an even more complex version than ALPS. The link was lost in the quoted
reply, so I'll include it again:
https://quicwg.org/base-drafts/draft-ietf-quic-http.html#section-7.2.4.2-7

This is fundamentally unavoidable if you want 0-RTT to be able to use
negotiated parameters. Any negotiated parameter available to 0-RTT *must* be
available predictively. Because it is predictive, mispredictions may occur.

RFC8470 likewise contains recommendations which also require more than a
"decrypt and forward" approach.


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

It's right here: https://tools.ietf.org/html/draft-vvv-tls-alps-00#section-3

>   For application protocols that support 0-RTT data, both the client
>   and the server have to remember the settings provided by the both
>   sides during the original connection.  If the client sends 0-RTT data
>   and the server accepts it, the ALPS values SHALL be the same values
>   as were during the original connection.  In all other cases
>   (including session resumption that does not result in server
>   accepting early data), new ALPS values SHALL be negotiated.
>
>   If the client wishes to send different client settings for the 0-RTT
>   session, it MUST NOT offer 0-RTT.  Conversely, if the server would
>   send different server settings, it MUST reject 0-RTT.  Note that the
>   ALPN itself is similarly required to match the one in the original
>   connection, thus the settings only need to be remembered or checked
>   for a single application protocol.


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

I don't think this follows. ALPS and half-RTT data happen at the same
round-trip. If the frontend is able to forward half-RTT data, it has
clearly decided on which backend to use by the time it's assembling the
ServerHello flight. It can as easily pick a backend-specific ALPS value as
it can pick backend-specific half-RTT data.

Beyond that, it's a question of what exactly your frontend/backend split
looks like. I gather you're worried about a deployment scenario where your
frontend is a TLS terminator, which has a boring pipe to the HTTP backend,
without any out-of-band signaling. (As opposed to having an HTTP frontend.)
In that case, the argument is that, since half-RTT data is just bytes, that
can be transparently forwarded over the pipe, whereas an ALPS signal
wouldn't. Is that right?

It's unlikely half-RTT data would work for that scenario. The frontend most
likely waits for the handshake to actually finish, before enabling the
pipe. Indeed, the security properties of the half-RTT point are kind of
subtle (particularly with client certs). Forwarding data then without
appropriate signaling is dangerous.

Such a frontend/backend split would also likely be unable to manage the
recommendations in RFC8470, the remembered settings vs. 0-RTT interactions,
the guarantee of half-RTT data being sent early enough, or the delimiting
information necessary to make a half-RTT settings work. For that matter, it
already needs some out-of-band signaling to communicate the ALPN protocol.

ALPS probably even helps this kind of deployment, by at least making it
possible to statically configure the settings. Static configuration risks
the footguns you mention below, but when all you've got is a boring pipe,
there aren't many options.

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

Again, this depends on where your frontend/backend split is, and what is
the communication between them. Note also that this hypothetical deployment
model already has a similar footgun around ALPN.

David