Re: [TLS] ALPS and TLS 1.3 half-RTT data
Victor Vasiliev <vasilvv@google.com> Tue, 02 February 2021 22:43 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 1CA3E3A0A87 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 2 Feb 2021 14:43:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.271
X-Spam-Level:
X-Spam-Status: No, score=-10.271 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 VuPuYnuQehge for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 2 Feb 2021 14:42:59 -0800 (PST)
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 774A53A0A73 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 2 Feb 2021 14:42:59 -0800 (PST)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1l74LU-000407-VY for ietf-http-wg-dist@listhub.w3.org; Tue, 02 Feb 2021 22:40:29 +0000
Resent-Date: Tue, 02 Feb 2021 22:40:28 +0000
Resent-Message-Id: <E1l74LU-000407-VY@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 <vasilvv@google.com>) id 1l74LT-0003zO-Jb for ietf-http-wg@listhub.w3.org; Tue, 02 Feb 2021 22:40:27 +0000
Received: from mail-wr1-x432.google.com ([2a00:1450:4864:20::432]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <vasilvv@google.com>) id 1l74LP-00026U-L1 for ietf-http-wg@w3.org; Tue, 02 Feb 2021 22:40:26 +0000
Received: by mail-wr1-x432.google.com with SMTP id d16so22092087wro.11 for <ietf-http-wg@w3.org>; Tue, 02 Feb 2021 14:40:23 -0800 (PST)
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=7BxCZHstr1RkZVpRXk+HewJKZNqFFA+iqN3Hw9iyHIg=; b=IH9mHZeup++25KX6XLxVjqrqcqTWY1tQhFKa2PKRt0h9621AJNDo3H1aUTLAfC/GjV 3mTIT1f+TYFzsNsZxYqR2Faeee10L56d/fC8ejD8D3rMeKZCH3qRT9zL0hEQGoEU5Hn2 1psQ2GhRKrSfZb7icE4Wxq0FsLmQ2MuXrvmNJQ49idl9pc4IaZQ4iwSOEVfdOdqxiial +DphQvefcNc7cFC425O6mrXZ1cuRo3ekNhT+dRPhEywvk6PjskzyFCMa6IUBVmIK2FYH rD94XwVcKJnJmoWkJtuXhxXJBSPopYXJmsg938drgk+tZ/33xktullN0/ALG+UV7i1eJ bS2Q==
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=7BxCZHstr1RkZVpRXk+HewJKZNqFFA+iqN3Hw9iyHIg=; b=G/OI+BzFv5M4Cv1Mo+e2z4B0PsDadY+hRr2afHW7T4t18csrwR8T8sGq/A/yT5gKO7 jLlmp9HSd24VToLbhuVELeKPtmd/x2UnDKaLQ/qmFBtMx/QFxiCml4zRlpq7iIWGBegi 1b0q69Esf+R3K1436xT+93o3zjpNuEyqcUMX8CVP49wPuMJVrnKj7DbOg8RXwDXc50xf U7UHY7Geq7KdEdPOsaagr6G9a1PO59mKKDJC6hy/yUMxJlyy7KOyKOmvzy/lRpL6M1Hm J6SetRTjgpYOboCQDYxWKBluSf0cC6VayyzypYCpQIBQE1aN0wPLqVXBJUchie3niwrE NiIg==
X-Gm-Message-State: AOAM531p3pE6ocUwi7YEq69svW0A494ENJ5grxPKopviQN4vJwxlv/Jn dwrPqZPSw1Cm3t3p+w20MF1+/9h93UVVvDS8iqcAGT+UuUI=
X-Google-Smtp-Source: ABdhPJzNbyqrPvJ/0mtdj/7+/F2f3uQUnp38n+xtOaiZsDpVLUhowq5KGxDx9YJYhgIUqk87SNAkzR1QWoMYz0bTzcQ=
X-Received: by 2002:a5d:5049:: with SMTP id h9mr278220wrt.404.1612305612078; Tue, 02 Feb 2021 14:40:12 -0800 (PST)
MIME-Version: 1.0
References: <160703055132.9234.3055845983488231389@ietfa.amsl.com> <CAF8qwaAUE4H2-JxCyQJSWW680=Xp9pkUOQdOQpbLhd-HjYaVcA@mail.gmail.com> <CAH_hAJGfKcDCLA7T_AnXHEK7Y4Qw814mkQcRNq-szF3-83L3Ag@mail.gmail.com> <CAAZdMafs-3xH8ZHaOfC9TZzj-qbfeg8H7b_FLOvkT4XZqChFvQ@mail.gmail.com> <CAH_hAJFZ-Gryiq-hKyX0U0SA96fU1t_eTZEdCEA_E2nRDwwkEA@mail.gmail.com> <CAH_hAJHqQw564VKMRjQTD1a0HXqz907BtO=F_FJ0aiXgHV_J9A@mail.gmail.com> <CAF8qwaChpjxhBtR9az0C58Qwscv5YM=PPcV3XDYb=1je2j4bdg@mail.gmail.com> <CAH_hAJHYVgHW9i=jgf-+TwQOBKyYgRi5OzJgqasdKKh7f937pA@mail.gmail.com> <CAH_hAJFJr=qRBk61n19Gyctqx0=Pw8e_F=CgtD98SreRAv94bg@mail.gmail.com>
In-Reply-To: <CAH_hAJFJr=qRBk61n19Gyctqx0=Pw8e_F=CgtD98SreRAv94bg@mail.gmail.com>
From: Victor Vasiliev <vasilvv@google.com>
Date: Tue, 02 Feb 2021 17:40:01 -0500
Message-ID: <CAAZdMadJ_pORNHc7-4cEUgArA4FwPd4PiFqE0NML5teCWtyb6A@mail.gmail.com>
To: Cory Benfield <cory@lukasa.co.uk>
Cc: David Benjamin <davidben@chromium.org>, "<tls@ietf.org>" <tls@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="00000000000047929005ba6227b5"
Received-SPF: pass client-ip=2a00:1450:4864:20::432; envelope-from=vasilvv@google.com; helo=mail-wr1-x432.google.com
X-W3C-Hub-DKIM-Status: validation passed: (address=vasilvv@google.com domain=google.com), signature is good
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: titan.w3.org 1l74LP-00026U-L1 bd8f217c69f1c09f0cb254ed228b6b84
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [TLS] ALPS and TLS 1.3 half-RTT data
Archived-At: <https://www.w3.org/mid/CAAZdMadJ_pORNHc7-4cEUgArA4FwPd4PiFqE0NML5teCWtyb6A@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38444
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>
The problems I personally have in mind (HTTP/3 datagrams, as used in MASQUE and WebTransport) are more relevant to HTTP/3 than /2, that said some of them do have HTTP/2 counterparts (WebTransport over HTTP/2, header compression static dictionary negotiation). On Mon, Feb 1, 2021 at 8:50 AM Cory Benfield <cory@lukasa.co.uk> wrote: > Oh, and I should say this out loud: my attitude to ALPS has softened > in the past two months or so. I definitely don't want my comments to > be perceived as being in opposition to the adoption of new work by > this WG: I just want to flesh out exactly what problems we're trying > to solve, so that we can accurately assess whether ALPS is the right > solution for them. > > ALPS is a good solution to some real problems. I want to make sure I > understand what problems it's solving in H2, so I can try to judge > whether I think it's a good solution for _those_ problems. > > On Mon, 1 Feb 2021 at 13:46, Cory Benfield <cory@lukasa.co.uk> wrote: > > > > On Fri, 29 Jan 2021 at 23:38, David Benjamin <davidben@chromium.org> > wrote: > > > > > > Hi all, > > > > > > > > > Thanks all for the feedback. I’ve tried to address it below, but > there's a lot of text, so please let me know if I’ve missed or > misunderstood any of your points. > > > > > > > > > Cory commented on SETTINGS_[HQ]PACK_ENABLE_STATIC_TABLES in > draft-vvv-httpbis-alps-00. I agree that is odd. We’ve uploaded a draft-01 > that drops it. > > > > > > > > > Cory also wrote: > > > > > > > I think the document does a good job laying out the difficulties with > > > > > > > half-RTT data, but it didn't convince me that ALPS is easier for H2. > > > > > > > > > To clarify, are you unconvinced that ALPS is easier than leaving H2 > alone, or that ALPS is easier than solving this problem with half-RTT? The > document’s aim is the latter. Your comment in Martin’s thread reads to me > like you agree with this. Am I interpreting that correctly? (I think > draft-thomson-httpbis-h2-0rtt roughly corresponds to Section 2.3 of my > document. Something like it would be necessary, but not sufficient, to > solve this with half-RTT.) > > > > > > > > > As to leaving H2 alone, doing nothing is indeed generally easier than > doing something. But this is perhaps not a useful criteria. :-) The > question is what’s the benefit of solving the problem. My interest is in > the privacy benefits of rethinking content negotiation. Victor has use > cases around WebTransport. The document cites some other uses. > > > > I am unconvinced that ALPS is easier than leaving H2 alone _and_ that > > I've not been sold on the criticality of adding content negotiation of > > this form. You say you're interested in the privacy benefits, but the > > draft doesn't state what those are expected to be, or what they're > > being compared to. I assume they're being compared to 0.5RTT data. If > > that's true, then sure, I can see the privacy benefits. However, > > that's not the status quo, and so not necessarily a meaningful > > comparison point. > > > > The document notes a single rationale: > > > > > One of the properties of the > > > mechanism as defined by both of those protocols is that the parties > > > start out without having access to the entirety of the peer's > > > settings. This means that they have to initially operate using the > > > default settings, and after receiving the SETTINGS frame, they have > > > to find a way to transition from the default to the exchanged > > > settings. > > > > I agree that this statement is an accurate representation of the state > > of things today. I also agree that having access to the settings > > before application traffic is negotiated will enable some use-cases > > that are otherwise tricky. But this is still not a concrete problem > > statement, merely a statement of hypothetical utility. > > > > > > > > My biggest concerns are around the need to tightly couple the TLS and > > > > > > > application layer stacks. > > > > > > > > > I agree this adds a non-I/O TLS interaction, but adding interactions > isn’t new. Many HTTP mechanisms touch TLS: > > > > > > RFC8473 uses TLS exporters. > > > RFC5929 specifies various TLS channel bindings interfaces for > authentication protocols. > > > RFC8470 integrates with the 0-RTT/1-RTT transition point. > > > ALPN itself uses TLS to select variations on HTTP. > > > Section 9.2.2 of RFC7540 specifies cipher suites for HTTP/2. > > > HTTP/2 cross-name pooling and HTTP’s general notion of authority are > tied to the TLS certificate. > > > Applications using client certificates care about the relation between > TLS-level authentication and HTTP messages. The web even has a notion of > “uncredentialed” HTTP fetches which shouldn’t send client certificates. > > > Secondary certificates use TLS exported authenticators. > > > > > > Systems and thus their problems span components. The question is how > best to split a solution across those components. The aim with ALPS is to > minimize coupling while still getting settings for the first client write. > We can build something piecemeal with half-RTT, ticket state, and early > data callbacks. Or we can abstract a notion of “protocol settings”, > configured and surfaced at well-defined points. I prefer the latter. > > > > Systems do span components, but reducing coupling between those > > systems is good. I agree that glomming things together out of an > > arbitrary collection of poorly supported protocol components is not a > > better solution than having a single extension point. I am pressing > > back on the idea that this problem requires coupling these systems at > > all. Well-designed, simple, extensible coupling is better than poorly > > designed coupling, but worse than no coupling at all. > > > > > As to the complexity, I think you may be overestimating it. It sounds > like your model has three components: TLS, HTTP/2, and some ALPN > dispatcher. And your concern is complexity in HTTP/2. Is that right? ALPS > should slot next to ALPN processing at the same points. For example: > > > > > > The dispatcher already must know which ALPN protocols are supported > and how to instantiate them. > > > Extend it so protocols can optionally be ALPS-aware. An ALPS-aware > protocol has a settings parameter in the instantiation function. It also > configures settings to send. This all happens at the same time as existing > ALPN setup. > > > The dispatcher runs the TLS handshake and gets an ALPN protocol as > before, plus now an ALPS value. > > > The dispatcher instantiates the protocol as before, but if ALPS was > negotiated, also passes a byte string to the ALPS-aware handler. Note the > extension ensures this can only happen if the protocol was configured as > ALPS-aware above. > > > > > > The protocol acts accordingly. If ALPS was negotiated, HTTP/2 would > apply the received settings to the initial peer state. It also knows the > initial local state is different and can skip sending some values. This is > added logic to HTTP/2, but I think it’s fairly minimal. (And we can > certainly figure out the exact details that would work best.) It even has > precedent in the HTTP Upgrade path for “http” URLs, so it's not even really > new. Also note that all this happens before any of the usual application > I/O. (I wasn't sure what you meant by "timing issues". Could you elaborate? > I read it to mean where the integration points were, so hopefully the > example above helps clarify. Also note that all of the logic above is > synchronous. We don't need new points in state machines to wait for data.) > > > > The above is, in various subtle ways, not going to match what I have > > to deal with. That's not the end of the world though: we shouldn't > > critique this general proposal based on one specific implementation. > > > > The timing issues here are around your "note that this happens before > > any of the usual application I/O". This is not a trivial invariant to > > enforce, and many stacks haven't had to bother. Highly integrated > > stacks such as those found in major user agents and standard HTTP > > servers tend to have this ironed out, but frameworks that support > > arbitrary configuration have extra work to do here. > > > > Nonetheless, I agree that the complexity here is not unmanageable. >
- ALPS and TLS 1.3 half-RTT data David Benjamin
- Re: [TLS] ALPS and TLS 1.3 half-RTT data Cory Benfield
- Re: ALPS and TLS 1.3 half-RTT data Martin Thomson
- Re: [TLS] ALPS and TLS 1.3 half-RTT data Victor Vasiliev
- Re: [TLS] ALPS and TLS 1.3 half-RTT data Cory Benfield
- Re: [TLS] ALPS and TLS 1.3 half-RTT data Cory Benfield
- Re: [TLS] ALPS and TLS 1.3 half-RTT data David Benjamin
- Re: [TLS] ALPS and TLS 1.3 half-RTT data Martin Thomson
- Re: [TLS] ALPS and TLS 1.3 half-RTT data Cory Benfield
- Re: [TLS] ALPS and TLS 1.3 half-RTT data Cory Benfield
- Re: [TLS] ALPS and TLS 1.3 half-RTT data David Benjamin
- Re: [TLS] ALPS and TLS 1.3 half-RTT data Victor Vasiliev
- Re: [TLS] ALPS and TLS 1.3 half-RTT data Cory Benfield