Re: [TLS] Application-Layer Protocol Settings

David Benjamin <davidben@chromium.org> Tue, 07 July 2020 19:14 UTC

Return-Path: <davidben@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 17C2B3A07CA for <tls@ietfa.amsl.com>; Tue, 7 Jul 2020 12:14:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.25
X-Spam-Level:
X-Spam-Status: No, score=-9.25 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no 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 BaHY0A4C6vVB for <tls@ietfa.amsl.com>; Tue, 7 Jul 2020 12:14:31 -0700 (PDT)
Received: from mail-pj1-x1044.google.com (mail-pj1-x1044.google.com [IPv6:2607:f8b0:4864:20::1044]) (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 79DF33A07FB for <TLS@ietf.org>; Tue, 7 Jul 2020 12:14:31 -0700 (PDT)
Received: by mail-pj1-x1044.google.com with SMTP id cv18so1197035pjb.1 for <TLS@ietf.org>; Tue, 07 Jul 2020 12:14:31 -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=pEoX3OXK7ndDnHp20diuDcqRDQcv9rICLKjdjRj8CWY=; b=TFSSIICd4Qv96KPHos00q+37R5eoRvQzgxhr0jlAXypoobamtujek44zyK1bBaK7C+ Bz351D6KlD3spw5q3m7brRdUT+gmBXLQulZCFwNm/pkkrHhNxyU7SfrH7Ch4oDV80gKw NtwNtE+0WlVd41BROqmV63uPC5TK3me4OCmTE=
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=pEoX3OXK7ndDnHp20diuDcqRDQcv9rICLKjdjRj8CWY=; b=Ya100vH7ZoGx46TmDg7xyFEcfQ9MrSMSHsAL4+EVJcDXQBc1LuSMOm0JyPd0PD0KaA OWY5ge/r6cMOuk4bwgln0PlUarIkUa/OeHhAIGf7vXOPTxahDfL9F3A2yoZ6aB2Dwex0 9Zo/YcYBUSiarOao28iQsKwgzfFLtkiiRvtsI53Apu7mlhX2IpWLy9dcY9BBavMCnhI+ DhI7rf11L+K7X79+DBji/RsvA4WxdjC0voQv0F2xHh83CE06MF7MDVanVR4fhcRu82ta 0FTMUKmAhZLILuuLJwXl1SnWuy4IJsu367I/J/A+YGYLaxTkhyJvNTQeqXPz6LJdd5Rn qsGg==
X-Gm-Message-State: AOAM533B9Rw4GSKf6ZIz7Y5fzp4uqBhZNy83AD0KOlhoaH/OKRRobah0 Jur18IUj87CexlvnfsN8kr8rr4HHmOlC97sPy++u
X-Google-Smtp-Source: ABdhPJwXcAaC5J+EsZKHg2wjMCGiCoZHSFRkbW9FNGOq3sXexRxzeQq9rSiMAZGeIgU2SwV77WYwesmh+9ipu2Fdm/w=
X-Received: by 2002:a17:90a:a78b:: with SMTP id f11mr5554838pjq.42.1594149270807; Tue, 07 Jul 2020 12:14:30 -0700 (PDT)
MIME-Version: 1.0
References: <CAAZdMaf2dKab0dJU8MLZc9JzEcVSvf8s9kgeZFo3tmsRtx2sNQ@mail.gmail.com> <CAHbrMsDLKdvapbg8EStXhqdyt=U9GnVgu3s2F1hDhQaOQKB3dA@mail.gmail.com>
In-Reply-To: <CAHbrMsDLKdvapbg8EStXhqdyt=U9GnVgu3s2F1hDhQaOQKB3dA@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Tue, 7 Jul 2020 15:14:14 -0400
Message-ID: <CAF8qwaA7eLJcAuV+kPxLOO-hpjFO9XBJAMhMiZCoawaT+aKC3Q@mail.gmail.com>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Cc: Victor Vasiliev <vasilvv=40google.com@dmarc.ietf.org>, "tls@ietf.org" <TLS@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="00000000000001ad4b05a9decd49"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/6UEMDpBTYj09GxJPb-FkmYR2zlo>
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 19:14:33 -0000

Hi Ben,

(I’ve covered many of these points in my reply to Martin, so you may want
to read that first.)

Any solution here involves a TLS change, even for servers which currently
send half-RTT settings. See my reply to Martin for why. The question then
is which is more complex. As a TLS implementor, ALPS would be a very
straightforward extension to implement, while the work involved to make
half-RTT SETTINGS work would be a mess.

Transparently sending a fixed buffer of half-RTT data was indeed something
we’d thought about and rejected. In some circumstances, it may cause
deadlocks with TCP
<https://mailarchive.ietf.org/arch/msg/tls/hymweZ66b2C8nnYyXF8cwj7qopc/>.
And we still need an indicator for the client to safely wait for it. I/O
patterns are part of the protocol.

It’s also not the case that non-uniform backends must disable 0-RTT. That
is what 0-RTT rejection logic is for. Non-uniform deployments may get less
0-RTT than a uniform deployment, but it won’t break things. This is already
the case (ALPN must match) and unavoidable with any predictive mechanism
like 0-RTT.

Finally, you’re right to think about the coupling between TLS and HTTP for
0-RTT, but I believe you have the conclusion backwards. The TLS stack must
be deeply aware of what is stored in the TLS session, so the server can
reject 0-RTT when the remembered values are incompatible with its current
configuration (see HTTP/3
<https://quicwg.org/base-drafts/draft-ietf-quic-http.html#section-7.2.4.2-7>).
Otherwise the client will act thinking the server supports some extension
when, in reality, it does not. (Perhaps the server had to roll the feature
back.)

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. Tighter coupling could be aware that, e.g.,
SETTINGS_MAX_CONCURRENT_STREAMS = 500 is compatible with 1000 but not 100.
The draft starts with the simplest option, given settings don’t change
much. It’s already the case that configuration changes, like cipher
preferences, may reject 0-RTT. (Note settings which do change can still be
sent in application data. ALPS’s purpose is to solve the reliable
negotiation problem, and any changing setting won’t be reliable in 0-RTT
anyway. Moving them out of ALPS entirely seems fairly clean.)

David

On Mon, Jul 6, 2020 at 10:23 PM Ben Schwartz <bemasc=
40google.com@dmarc.ietf.org> wrote:

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