From ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=ietf.org@listhub.w3.org Tue Dec 12 14:05:02 2023 Return-Path: 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 DF25CC14CE30 for ; Tue, 12 Dec 2023 14:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtfUcHdPdrNK for ; Tue, 12 Dec 2023 14:04:59 -0800 (PST) Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB7EC151099 for ; Tue, 12 Dec 2023 14:04:58 -0800 (PST) Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from ) id 1rDAru-000wr8-JY for ietf-http-wg-dist@listhub.w3.org; Tue, 12 Dec 2023 22:04:46 +0000 Resent-Date: Tue, 12 Dec 2023 22:04:46 +0000 Resent-Message-Id: Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rDArr-000wq6-3r for ietf-http-wg@listhub.w3.org; Tue, 12 Dec 2023 22:04:43 +0000 Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]) by mimas.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rDAro-005hWp-BD for ietf-http-wg@w3.org; Tue, 12 Dec 2023 22:04:42 +0000 Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-33635d11dabso755433f8f.0 for ; Tue, 12 Dec 2023 14:04:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702418676; x=1703023476; darn=w3.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=G7TAPkkvcu0i+T9T2u0zYJHz6yX43tLHNxYHpj8NBIg=; b=A7xykfZnrMY1Rlm6/TWhrNXrGXDW1f+ts3shi8oOzj2pfOGqSlX7x8zMa0lFU89Szk 5TlIyD7TGbYCNQ2+PYL/hj2i7RqE6zRi2VzaEif2QVXAyGThXWGIk5cFfnce6xfctT5Z UPguARyCPb1OC/Uap1gIAMtNKTT7RZrxFp6r6EUd/wHdlAJHW6f7snJy+fkQAF/rlsPv hetB0x56KsPhwXUb1JzgzWI9/b/xyYi1PcYcTDWK+QB3WjAIqDJKc9kMNp82JURi4ivZ 1EFZs1l4ZcwaLbljdhZZnNO2PeiirOw8+K9cDnmXsMXumXJFh8sFf148auRUCp9o9Sle uqhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702418676; x=1703023476; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=G7TAPkkvcu0i+T9T2u0zYJHz6yX43tLHNxYHpj8NBIg=; b=pUfO9/D8fwbtayweCCJ4/56/7ztOfrwFNClWkNlIKLTXnrdi/Aw1zG+WzYPuhEKC7U goA9H/EDZ0GECO8uKre/f+j6n9y3xGZZnNfwf7cx3yWqxoaMW9ayVcshF9J8IH3Ps9MX eal0sX5rX5X4FvNr0f4qHv61BfuHagEhFsbx05QbxMYFrRjpu5mVJQCWquXkbcJDDYON 6V1m7KF6gDYN2QlyPT6sUYagtJcRjdPolVD+/iwnADdcC8L+9zL/UxvIWboD/Rvc04Tt UIYQ0Kgh1aNC8okn/8gTtF11CZGndSYtQ2Dg1/rLIWnNUkXCMU1y0O2P+nBMqdfTDbYJ 0WBg== X-Gm-Message-State: AOJu0YyCKMDksG59jtg73y8jf6pgeV8d/mHCMBqaR4JJ6grPhILJxPEj +Axn+9P/rkl7RsMnd5qclVW22gV9WfwmMA28yUY= X-Google-Smtp-Source: AGHT+IFvr4SWErgrMAtWEGEo7Dju/CbNzJ/JnBLoSz77qMUJbiijCkPAKT8UgbjAfqf93MFvc/W9ovvntR9M9xZxZw0= X-Received: by 2002:a5d:6a85:0:b0:333:3518:c6a5 with SMTP id s5-20020a5d6a85000000b003333518c6a5mr3919840wru.40.1702418675829; Tue, 12 Dec 2023 14:04:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rory Hewitt Date: Tue, 12 Dec 2023 14:04:24 -0800 Message-ID: To: Mike Bishop Cc: David Benjamin , HTTP Working Group Content-Type: multipart/alternative; boundary="0000000000006e8f2f060c573c5f" Received-SPF: pass client-ip=2a00:1450:4864:20::42c; envelope-from=roryhewitt@gmail.com; helo=mail-wr1-x42c.google.com X-W3C-Hub-DKIM-Status: validation passed: (address=roryhewitt@gmail.com domain=gmail.com), signature is good X-W3C-Hub-Spam-Status: No, score=-2.9 X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_WL=-1 X-W3C-Scan-Sig: mimas.w3.org 1rDAro-005hWp-BD e7570dab2363dda4b9ce90dea42728df X-Original-To: ietf-http-wg@w3.org Subject: Re: The qpack_static_table_version TLS extension (Draft version 02) Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/51676 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: --0000000000006e8f2f060c573c5f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah, if ALPS 'can be used as a de facto negotiation protocol' then life is much easier - although does the first settings frame there come from client or server? In any event, as long as one of them is able to send a list of supported variant/length combinations and the other can reply with their chosen one from that supported list, then we're golden. On Tue, Dec 12, 2023 at 8:06=E2=80=AFAM Mike Bishop = wrote: > ALPS not being a negotiation mechanism comes from the HTTP/QUIC idea that > settings are not responses to each other, but unilateral declarations abo= ut > a client=E2=80=99s state. The protocol then needs to describe what is saf= e to send > / how to interpret things being received based on what is seen in SETTING= S. > > > > A more complex approach might be to assume the peer will have seen the > SETTINGS you sent as well and define an algorithm to =E2=80=9Cnegotiate= =E2=80=9D by > combining what was sent and what was received. No HTTP extensions to dat= e > have gone this far, largely because guarantees about ordering get a bit > squishy, especially in QUIC. The key benefit of ALPS is a guarantee that > both sides have seen and processed the settings by the time the TLS > handshake completes, so you can rely on such an algorithm in 1-RTT data. > (0-RTT might still have sharp edges.) > > > > *From:* Rory Hewitt > *Sent:* Monday, November 27, 2023 8:49 PM > *To:* David Benjamin > *Cc:* HTTP Working Group > *Subject:* Re: The qpack_static_table_version TLS extension (Draft > version 02) > > > > Hey David, > > > > Focusing in on what is (IMO) the most important bit of your response: > > > > Right, I think that's the ALPN vs ALPS question. If we believe a mess of > vendor-specific static tables is worthwhile, we should do this with as > subfeature and do something like ALPS. If we don't believe this is that > important, and that we can live with a single, infrequently-updated, > universal static table, let's just define h2.1 and move on with life. > > > > Given that the dynamic mechanism already compresses repeat headers after > the first utterance, and that h2 and h3 are quite good at connection reus= e, > I suspect the h2.1 path is just fine. Or are you seeing that people are > trying to make vendor-specific static tables already? I've not heard of > this happening. > > > > I haven't seen any evidence that any vendors are creating their own stati= c > tables. But if I were, let's say, Google (random example, I swear), I wou= ld > note that Chrome appears to send a number of headers with every request f= or > a web page, some of which are very big, and would therefore > benefit significantly from being added to a static table, e.g.: > > > > > Accept: text/html,application/xhtml+xml,application/xml;q=3D0.9,image/avi= f,image/webp,image/apng,*/*;q=3D0.8,application/signed-exchange;v=3Db3;q=3D= 0.7 > > Sec-Ch-Ua: "Google Chrome";v=3D"119", "Chromium";v=3D"119", > "Not?A_Brand";v=3D"24" > User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 > (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36 > > > > Leaving aside the discussion of if/when the User-Agent header will be > frozen and what form it will take at that point, that's a lot of bytes > (340-ish)! Using static table entries for name/value combos reduces that = to > about 12 bytes. Dynamic table Huffman coding compression doesn't even get > close. > > > > So I can certainly see vendors seeing the benefit of being allowed to > define small (possibly vendor-specific) tables as a noticeable benefit ov= er > and above the h2.1 path. > > > > If ALPS works as a negotiation mechanism, then coolio. I was mistakenly > under the impression that it wouldn't. > > > > Rory > > > > On Mon, Nov 27, 2023 at 12:43=E2=80=AFPM David Benjamin > wrote: > > On Mon, Nov 27, 2023 at 3:21=E2=80=AFPM Rory Hewitt wrote: > > > > > > On Mon, Nov 27, 2023 at 10:57=E2=80=AFAM David Benjamin > wrote: > > > FWIW, I'm inclined to come out against the idea of using ALPS rather > than a TLS extension, primarily because ALPS is specifically NOT designed > to be a negotiation mechanism. > > I think this may be fixating too much on the name and missing what the > extension actually does. > > > > As one of the folks involved in the original design, I think I can > authoritatively say this is false. We named ALPS S for settings simply > because "ALPS" is easy to pronounce, and because the corresponding messag= e > in h2 and h3 is called SETTINGS. It is absolutely designed to communicate > application protocol capabilities and preferences... in other words, > negotiation. Indeed we specifically had [HQ]PACK static tables in mind as= a > use case when designing this. See here: > > > https://www.ietf.org/archive/id/draft-davidben-tls-alps-half-rtt-00.html#= section-1-2 > > > > Ah - I was indeed fixating on this (Section 3 - semantics): > > ALPS is _not_ a negotiation mechanism: there is no notion of rejecting pe= er's settings, and the settings are not responses to one another. > > > > Ah, forgot about that text. This document is old. :-) I believe this was > just trying to capture that each side's blobs were expected to be > configured mostly statically. See the immediately following text: > > > > > Nevertheless, it is possible for parties to coordinate behavior by, for > instance, requiring a certain parameter to be present in both client and > server settings. This makes ALPS mechanism similar to QUIC transport > parameters [I-D.ietf-quic-transport] or HTTP/2 SETTINGS frame [RFC7540], > but puts it in contrast to similar mechanisms in TLS. > > > > I.e., this was just trying to capture that this is akin to the QUIC and > HTTP pattern, rather than the TLS pattern where one side's message is > directly in response to the other. We didn't want to invent a whole new > pattern and just try to patch up the issues with the existing one. (At th= e > end of the day, you just need *something* to signal that the new thing is > happening, and then the rest is just protocol engineering.) > > > > Though also I don't consider these details to be that fundamental. We > probably could have allowed the client one to be in response to the serve= r > one, if people prefer that. It just would have encouraged a more complex, > asymmetric callback API. Such a callback would be particularly challengin= g > considering that your h2 logic may be far from your TLS terminator in som= e > deployments. Thus it seemed cleanest to use static messages and have > everything flow from there. (You just need *something* that consistently > signals to both sides, at the right time, that the new thing is happening= .) > > > > > Of course basic ALPN IS a negotiation mechanism (it's right there in th= e > name!) > > > > I think this is further fixating on naming coincidences. The N in ALPN > doesn't mean "Negotiation *within* an Application-Layer Protocol" but > "Negotiation *of* Application-Layer Protocol". We couldn't name ALPS > after the former because ALPN was already taken and it's a bit ambiguous. > > > > > maybe what I *want* is a brand-new ALSN (Application-Layer Stuff > Negotiation) which would encompass ALPN and also QPACK static table > negotiation and anything else which needs to be negotiated. > > > > If you work through that design, I think you will quickly reinvent > something akin to the ALPN + ALPS combo. > > > > Yeah, I'm aware of that :) It was meant somewhat (OK, almost entirely) in > jest... > > > > > > Really all this is just the standard set of tradeoffs in protocol design > between minting new top-level versions or optional extensions within a > version: > > > > - If we think this is just a sequential series of infrequently updated, > essentially universal features, this can be rolled up into h2.1, h2.2, > h2.3, etc., once we've settled on a cadence/criteria for how often we wan= t > to mint new ones of these. > > > > - If we think there may be multiple static tables for different folks, or > that we want to define new ones frequently, or that maybe one might want = to > not have a static table at all, these tables may need to be one of severa= l > orthogonal features. We don't have a great story for this in h2 and h3 > today. ALPS aims to fill that gap, and fill in a few papercuts we left in > h3 around how SETTINGS and 0-RTT tickets interact. > > > > I admit I've only been lurking in the half-rtt data discussion. > > > > TBH, in many ways it would make sense to use the ALPS as defined in > https://www.ietf.org/archive/id/draft-davidben-tls-alps-half-rtt-00.html#= name-using-alps > for my use-case (QPACK static table), since in that case the server sends > the ALPS h2 settings first and the client effectively 'responds', so a > negotiation would start from the server, if I understand correctly. > > > > FWIW, while I believe ALPS is the right starting point for problems shape= d > like the second case, I don't personally have any horse in whether new > static tables should look like the first or second. The second seems > perfectly defensible, once we've switched from "never defining new ALPNs" > to "occasionally defining new ALPNs". > > > > Sorry, just noticed that I mixed up "first" and "second" here. (This is > what I get for referencing things by numbers!) That was probably confusin= g. > I meant to say that the *first* seems perfectly defensible. That is, I > think: > > - *If* you want to model this as lots of orthogonal features, something > ALPS-y is the right shape. > - But just rolling up common static table updates into h2.1, h2.2, etc., > whenever we find we need to mint new ones, seems likely fine. > > > > Which is fine by me. > > > > My concern is really about us having defined how h3 headers should be sen= t > (QPACK, combo of static and dynamic tables) but not having a mechanism to > extend that going forwards for specific use-cases. > > > > IMO, the worst-case scenario is where different client/server vendors > (e.g. Apple, Amazon, etc.) decide to create their own additional static > table entries (or simply much smaller and more limited static tables) in = an > effort to reduce bytes on the wire for things like assistants (Siri, Alex= a, > etc.) which only send a few headers, several of which are vendor-specific > and which only contact servers which are expecting those requests. For ea= ch > individual vendor, doing that would absolutely make sense and I wouldn't > blame them for doing that, but overall it would make it much more complex > to design common testing tools or utilities like cURL or simply to mainta= in > some sort of standardization. > > > > Right, I think that's the ALPN vs ALPS question. If we believe a mess of > vendor-specific static tables is worthwhile, we should do this with as > subfeature and do something like ALPS. If we don't believe this is that > important, and that we can live with a single, infrequently-updated, > universal static table, let's just define h2.1 and move on with life. > > > > Given that the dynamic mechanism already compresses repeat headers after > the first utterance, and that h2 and h3 are quite good at connection reus= e, > I suspect the h2.1 path is just fine. Or are you seeing that people are > trying to make vendor-specific static tables already? I've not heard of > this happening. > > > > David > > > > On Mon, Nov 27, 2023 at 1:12=E2=80=AFPM Rory Hewitt wrote: > > > - Bumping this to request some input on my changes... > > FWIW, I'm inclined to come out against the idea of using ALPS rather than > a TLS extension, primarily because ALPS is specifically NOT designed to b= e > a negotiation mechanism. Of course basic ALPN IS a negotiation mechanism > (it's right there in the name!), so maybe what I *want* is a brand-new AL= SN > (Application-Layer Stuff Negotiation) which would encompass ALPN and also > QPACK static table negotiation and anything else which needs to be > negotiated. It could probably include ALPS as well, since that could just > not use the 'negotiation' concept... But I fear that's a pipe dream :) > > - > - *From*: Rory Hewitt > > > - *Date*: Thu, 9 Nov 2023 16:03:23 -0800 > - *To*: HTTP Working Group >, > TLS List >, > "Hewitt, Rory" > > > - *Message-ID*: ciEcEYrJOFzxcKA@mail.gmail.com> > > Hey folks, > > > > Following my presentation at the meeting at IETF 118 today (thanks for > > taking it easy on me, as this was my first IETF appearance as well as bei= ng > > my first I-D), I have created another version of my I-D: > > > > https://www.ietf.org/archive/id/draft-hewitt-ietf-qpack-static-table-vers= ion-02.html > > > > Significant changes from version-01 are as follows: > > > > 1. I changed references to registry "Version" to "Variant" to make it cle= ar > > that they could be very different. > > > > 2. I added a section on vendor-defined registries, which would contain > > static tables that might be much smaller and/or contain vendor-specific > > field names or values - for instance for personal assistants and APIs whi= ch > > only use a very small set of headers with known values. > > > > 3. In the QPACK Static Table Background > > > > section, > > I added an example showing how the use of a static table can significantl= y > > reduce bytes on the wire by passing only 2- or 3-byte references to much > > longer strings that are known to both client and server. > > > > 4. The details of the TLS extension has been changed so that it is no > > longer simply a Variant/Length pair, but similarly to ciphersuite support= , > > it is (when passed in the ClientHello) an array of Variant/Length > > combinations supported by the client and (when passed in the ServerHello)= a > > single negotiated Variant/Length pair which will be used by both client a= nd > > server. > > > > Note that the draft still refers to this as a "TLS extension" - I think > > many of us agree that it would be preferable if it were defined in ALPS, > > but since ALPS support is still minimal, I'll keep referring to it as a T= LS > > extension for now. Given that, I would really appreciate any comments on > > the high-level concept, on the understanding that it may not end up being= a > > TLS extension. Speaking of which, where can I find details of why ALPS wa= s > > not taken up - it was mentioned in the meeting that there were 'concerns' > > about ALPS, but I'm not clear on what they were or who was concerned - HT= TP > > WG or TLS WG or both or some other entity? > > > > Finally, I'm still trying to build a test harness to determine whether th= e > > benefits of any additional compression make sense - is this even worth th= e > > hassle? I would greatly appreciate any help on this - you'll get co-autho= r > > credit, for what that's worth :) > > > > Thanks, > > > > Rory > > *Received on* Friday, 10 November 2023 00:03:41 UTC > > > > > -- > > Rory Hewitt > > https://www.linkedin.com/in/roryhewitt > > > > > -- > > Rory Hewitt > > https://www.linkedin.com/in/roryhewitt > --=20 Rory Hewitt https://www.linkedin.com/in/roryhewitt --0000000000006e8f2f060c573c5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, if ALPS 'can be used as a de facto nego= tiation protocol' then life is much easier - although does the first se= ttings frame there come from client or server?

In any event, as long= as one of them is able to send a list of supported variant/length combinat= ions and the other can reply with their chosen one from that supported list= , then we're golden.

On Tue, Dec 12, 2023 at 8:06=E2=80=AFAM Mike = Bishop <mbishop@evequefou.be= > wrote:

ALPS not being a negotiation mechanism comes from th= e HTTP/QUIC idea that settings are not responses to each other, but unilate= ral declarations about a client=E2=80=99s state. The protocol then needs to= describe what is safe to send / how to interpret things being received based on what is seen in SETTINGS.

=C2=A0

A more complex approach might be to assume the peer = will have seen the SETTINGS you sent as well and define an algorithm to =E2= =80=9Cnegotiate=E2=80=9D by combining what was sent and what was received.= =C2=A0 No HTTP extensions to date have gone this far, largely because guarantees about ordering get a bit squishy, especially in QUIC.= =C2=A0 The key benefit of ALPS is a guarantee that both sides have seen and= processed the settings by the time the TLS handshake completes, so you can= rely on such an algorithm in 1-RTT data.=C2=A0 (0-RTT might still have sharp edges.)

=C2=A0

From: Rory Hewitt <rory.hewitt@gmail.com>
Sent: Monday, November 27, 2023 8:49 PM
To: David Benjamin <davidben@chromium.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: The qpack_static_table_version TLS extension (Draft ver= sion 02)

=C2=A0

Hey David,

=C2=A0

Focusing in on what is (IMO) the most important bit of your= response:

=C2=A0

Right, I think that's the ALPN vs ALPS question. If we bel= ieve a mess of vendor-specific static tables is worthwhile, we should do th= is with as subfeature and do something like ALPS. If we don't believe this is that important, and that we can live= with a single, infrequently-updated, universal static table, let's jus= t define h2.1 and move on with life.

=C2=A0

Given that the dynamic mechanism already compresses repeat hea= ders after the first utterance, and that h2 and h3 are quite good at connec= tion reuse, I suspect the h2.1 path is just fine. Or are you seeing that people are trying to make vendor-specific sta= tic tables already? I've not heard of this happening.

=C2=A0

I haven't seen any evidence that any vendors are creati= ng their own static tables. But if I were, let's say, Google (random ex= ample, I swear), I would note that Chrome appears to send a number of headers with every request for a web page, some of whi= ch are very big, and would therefore benefit=C2=A0significantly from being = added to a static table, e.g.:

=C2=A0

Accept:=C2=A0text/html,application/xhtml+xml,application/xm= l;q=3D0.9,image/avif,image/webp,image/apng,*/*;q=3D0.8,application/signed-e= xchange;v=3Db3;q=3D0.7

Sec-Ch-Ua: "Google Chrome";v=3D"119", &= quot;Chromium";v=3D"119", "Not?A_Brand";v=3D"= 24"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (K= HTML, like Gecko) Chrome/119= .0.0.0 Safari/537.36

=C2=A0

Leaving aside the discussion of if/when the User-Agent head= er will be frozen and what form it will take at that point, that's a lo= t of bytes (340-ish)! Using static table entries for name/value combos reduces that to about 12 bytes. Dynamic table Huffma= n coding compression doesn't even get close.

=C2=A0

So I can certainly see vendors seeing the benefit=C2=A0of b= eing allowed to define small (possibly vendor-specific) tables as a noticea= ble benefit over and above the h2.1 path.

=C2=A0

If ALPS works as a negotiation mechanism, then coolio. I wa= s mistakenly under the impression that it wouldn't.

=C2=A0

Rory

=C2=A0

On Mon, Nov 27, 2023 at 12:43=E2=80=AFPM David Benja= min <davidben= @chromium.org> wrote:

On Mon, Nov 27, 2023 at 3:21=E2=80=AFPM Rory Hewitt = <rory.hewitt@= gmail.com> wrote:

=C2=A0

=C2=A0

On Mon, Nov 27, 2023 at 10:57=E2=80=AFAM David Benja= min <davidben= @chromium.org> wrote:

> FWIW, I'm inclined to come out against the = idea of using ALPS rather than a TLS extension, primarily because ALPS is s= pecifically NOT designed to be a negotiation mechanism.

I think this may be fixating too much on the name and missing what the exte= nsion actually does.

=C2=A0

As one of the folks involved in the original design,= I think I can authoritatively say this is false. We named ALPS S for setti= ngs simply because "ALPS" is easy to pronounce, and because the c= orresponding message in h2 and h3 is called SETTINGS. It is absolutely designed to communicate application protocol ca= pabilities and preferences... in other words, negotiation. Indeed we specif= ically had [HQ]PACK static tables in mind as a use case when designing this= . See here:

=C2=A0

Ah - I was indeed fixating on this (Section 3 - semantics):= 

ALPS is _not_ a negotiation mechanism: the=
re is no notion of rejecting peer's settings, and the settings are not =
responses to one another.

=C2=A0

Ah, forgot about that text. This document is old. :-= ) I believe this was just trying to capture that each side's blobs were= expected to be configured mostly statically. See the immediately following= text:

=C2=A0

> Nevertheless, it is possible for parties to coo= rdinate behavior by, for instance, requiring a certain parameter to be pres= ent in both client and server settings. This makes ALPS mechanism similar t= o QUIC transport parameters [I-D.ietf-quic-transport] or HTTP/2 SETTINGS frame [RFC7540], but puts it in contrast to similar mec= hanisms in TLS.

=C2=A0

I.e., this was just trying to capture that this is a= kin to the QUIC and HTTP pattern, rather than the TLS pattern where one sid= e's message is directly in response to the other. We didn't want to= invent a whole new pattern and just try to patch up the issues with the existing one. (At the end of the day, you jus= t need something=C2=A0to signal that the new thing is happening, and then t= he rest is just protocol engineering.)

=C2=A0

Though also I don't consider these details to be= that fundamental. We probably could have allowed the client one to be in r= esponse to the server one,=C2=A0if people prefer that. It just would have e= ncouraged a more complex, asymmetric callback API. Such a callback would be particularly challenging considering that yo= ur h2 logic may be far from your TLS terminator in some deployments. Thus i= t seemed cleanest to use static messages and have everything flow from ther= e. (You just need something=C2=A0that consistently signals to both sides, at the right= time, that the new thing is happening.)

=C2=A0

> Of course basic ALPN IS a negotiation mechanism= (it's right there in the name!)

=C2=A0

I think this is further fixating on naming coinciden= ces. The N in ALPN doesn't mean "Negotiation within an Application-Layer Protocol" but "Negotiation = of=C2=A0Application-Layer Protocol". We couldn't name ALPS aft= er the former because ALPN was already taken and it's a bit ambiguous.<= u>

=C2=A0

>=C2=A0maybe what I *want* is a brand-new ALSN (A= pplication-Layer Stuff Negotiation) which would encompass ALPN and also QPA= CK static table negotiation and anything else which needs to be negotiated.=

=C2=A0

If you work through that design, I think you will qu= ickly reinvent something akin to the ALPN=C2=A0+ ALPS combo.<= /p>

=C2=A0

Yeah, I'm aware of that :) It was meant somewhat (OK, a= lmost entirely) in jest...

=C2=A0

=C2=A0

Really all this is just the standard set of tradeoff= s in protocol design between minting new top-level versions or optional ext= ensions within a version:

=C2=A0

- If we think this is just a sequential series of in= frequently updated, essentially universal features, this can be rolled up i= nto h2.1, h2.2, h2.3, etc., once we've settled on a cadence/criteria fo= r how often we want to mint new ones of these.

=C2=A0

- If we think there may be multiple static tables fo= r different folks, or that we want to define new ones frequently, or that m= aybe one might want to not have a static table at all, these tables may nee= d to be one of several orthogonal features. We don't have a great story for this in h2 and h3 today. ALP= S aims to fill that gap, and fill in a few papercuts we left in h3 around h= ow SETTINGS and 0-RTT tickets interact.

=C2=A0

I admit I've only been lurking in the half-rtt data dis= cussion.

=C2=A0

TBH, in many ways it would make sense to use the ALPS as de= fined in=C2=A0https://www.ietf.= org/archive/id/draft-davidben-tls-alps-half-rtt-00.html#name-using-alps for my use-case (QPACK static table), since in that case the server sends = the ALPS h2 settings first and the client effectively 'responds', s= o a negotiation would start from the server, if I understand correctly.<= /u>

=C2=A0

FWIW, while I believe ALPS is the right starting poi= nt for problems shaped like the second case, I don't personally have an= y horse in whether new static tables should look like the first or second. = The second seems perfectly defensible, once we've switched from "never defining new ALPNs" to "= ;occasionally defining new ALPNs".

=C2=A0

Sorry, just noticed that I mixed up "first"= ; and "second" here. (This is what I get for referencing things b= y numbers!) That was probably confusing. I meant to say that the first seems perfectly defensible. That is, I think:

- If you want to model this as lots of orthogonal features, somethin= g ALPS-y is the right shape.
- But just rolling up common static table updates into h2.1, h2.2, etc., wh= enever we find we need to mint new ones, seems likely fine.

=C2=A0

Which is fine by me.

=C2=A0

My concern is really about us having defined how h3 headers= should be sent (QPACK, combo of static and dynamic tables) but not having = a mechanism to extend that going forwards for specific use-cases.

=C2=A0

IMO, the worst-case scenario is where different client/serv= er vendors (e.g. Apple, Amazon, etc.) decide to create their own additional= static table entries (or simply much smaller and more limited=C2=A0static tables) in an effort to reduce bytes on the w= ire for things like assistants (Siri, Alexa, etc.) which only send a few he= aders, several of which are vendor-specific and which only contact servers = which are expecting those requests. For each individual vendor, doing that would absolutely make sense and I would= n't blame them for=C2=A0doing that, but overall it would make it much m= ore complex to design common testing tools or utilities like cURL or simply= to maintain some sort of standardization.

=C2=A0

Right, I think that's the ALPN vs ALPS question.= If we believe a mess of vendor-specific static tables is worthwhile, we sh= ould do this with as subfeature and do something like ALPS. If we don't= believe this is that important, and that we can live with a single, infrequently-updated, universal static table, l= et's just define h2.1 and move on with life.

=C2=A0

Given that the dynamic mechanism already compresses = repeat headers after the first utterance, and that h2 and h3 are quite good= at connection reuse, I suspect the h2.1 path is just fine. Or are you seei= ng that people are trying to make vendor-specific static tables already? I've not heard of this happenin= g.

=C2=A0

David

=C2=A0

On Mon, Nov 27, 2023 at 1:12=E2=80=AFPM Rory Hewitt = <rory.hewitt@= gmail.com> wrote:

  • Bumpin= g this to request some input on my changes...

FWIW, I'm inclined to come out against the i= dea of using ALPS rather than a TLS extension, primarily because ALPS is sp= ecifically NOT designed to be a negotiation mechanism. Of course basic ALPN IS a negotiation=C2=A0mechanism (it's right there= in the name!), so maybe what I *want* is a brand-new ALSN (Application-Lay= er Stuff Negotiation) which would encompass ALPN and also QPACK static tabl= e negotiation and anything=C2=A0else which needs to be negotiated. It could probably include ALPS as well, since that could= just not use the 'negotiation' concept... But I fear that's a = pipe dream :)

Hey folks,
=C2=A0
Following my presentation at the meeting at IETF 118 today (thanks for=

taking it easy on me, as this was my first IETF appearance as well as =
being
my first I-D), I have created another version of my I-D:=

=C2=A0
https://www.ietf.org/archive/i=
d/draft-hewitt-ietf-qpack-static-table-version-02.html

=C2=A0


Significant changes from version-01 are as follows:

=C2=A0


1. I changed references to registry "Version" to "Varia=
nt" to make it clear


that they could be very different.


=C2=A0


2. I added a section on vendor-defined registries, which would contain=



static tables that might be much smaller and/or contain vendor-specifi=
c


field names or values - for instance for personal assistants and APIs =
which


only use a very small set of headers with known values.<=
/pre>

=C2=A0


3. In the QPACK Static Table Background


<https://www.ietf.org/archive/id/draft-hewitt-ietf-qpack-static-table=
-version-02.html#name-qpack-static-table-backgrou>

section,


I added an example showing how the use of a static table can significa=
ntly


reduce bytes on the wire by passing only 2- or 3-byte references to mu=
ch


longer strings that are known to both client and server.=



=C2=A0


4. The details of the TLS extension has been changed so that it is no<=
u>


longer simply a Variant/Length pair, but similarly to ciphersuite supp=
ort,


it is (when passed in the ClientHello) an array of Variant/Length


combinations supported by the client and (when passed in the ServerHel=
lo) a


single negotiated Variant/Length pair which will be used by both clien=
t and


server.


=C2=A0


Note that the draft still refers to this as a "TLS extension"=
; - I think


many of us agree that it would be preferable if it were defined in ALP=
S,


but since ALPS support is still minimal, I'll keep referring to it=
 as a TLS


extension for now. Given that, I would really appreciate any comments =
on


the high-level concept, on the understanding that it may not end up be=
ing a


TLS extension. Speaking of which, where can I find details of why ALPS=
 was


not taken up - it was mentioned in the meeting that there were 'co=
ncerns'


about ALPS, but I'm not clear on what they were or who was concern=
ed - HTTP


WG or TLS WG or both or some other entity?


=C2=A0


Finally, I'm still trying to build a test harness to determine whe=
ther the


benefits of any additional compression make sense - is this even worth=
 the


hassle? I would greatly appreciate any help on this - you'll get c=
o-author


credit, for what that's worth :)


=C2=A0


Thanks,


=C2=A0


Rory


Received on=C2=A0Friday, 10 November 2023 00:03:41 UTC


=C2=A0

--


=C2=A0

--



--
--0000000000006e8f2f060c573c5f--