[TLS] The qpack_static_table_version TLS extension (Draft version 02)

Rory Hewitt <rory.hewitt@gmail.com> Fri, 10 November 2023 00:03 UTC

Return-Path: <roryhewitt@gmail.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 04198C1705E6 for <tls@ietfa.amsl.com>; Thu, 9 Nov 2023 16:03:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=unavailable 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 X6qXNERSJCZ7 for <tls@ietfa.amsl.com>; Thu, 9 Nov 2023 16:03:37 -0800 (PST)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24614C17C536 for <tls@ietf.org>; Thu, 9 Nov 2023 16:03:37 -0800 (PST)
Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-507bd644a96so2039564e87.3 for <tls@ietf.org>; Thu, 09 Nov 2023 16:03:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699574615; x=1700179415; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=/e/H6UrCrN0zZIpY6Ny62rG+vG2FDwgn1ew23t8Q/3o=; b=l0im9LaeAe6K31/q2flldHs3STil7UOG/qiGhvTPwiJPZP3Za7BsScorokhhvfeT1W 9NcLzlfFRyO4fC6zB5E7jJfFNPDt7F3i+EMoKkaUdGZZybnM7ejvE3Up3ixBkMYbZuGi r0gTqVK2xdg/CATUx6/9hetxgiOEeiFVjt3tS4SHSomhH5ouNeyjIIpF+TaTPMvSMJ7s YQ7vt2nYrXCU14N4c00XhqsYBzJmSXv9r2OgnKSTJPIrlv0vOyMKANTo3IhkGGXi5sPO Fjh6VUs8zBrZITAL5p4CYxo7OkkbYQGLCxcpgZ3m4hCuUQ3EcFDHpXB/U6RO9ZFK3IdF neaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699574615; x=1700179415; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=/e/H6UrCrN0zZIpY6Ny62rG+vG2FDwgn1ew23t8Q/3o=; b=Jw6PoPqk6jMAzZlE8t8a4h11JCbhjG/30Nkgie9cMS6D8xs6iY12vA0Kw5gQQ4z1Cb BpfJZsjTHgVhbY7JdP9LG0rwEK5oMaxPt5WQLJ+/TA1ZEo02obAkHGGwAPPgKmaO8WuG 0JoMd7dYOHDv9c9FCdpcs5ozht8T2COV8/USNl7bxwoGHeU9soMsshjVYT/J3r0pL+t3 RaMkCYtjlV4Yc/k/CHiVdtsXYlC2+6e8qVe6FZO+rH/eXNYnTERVHbTalUWwY5GYNB2k 1vglAhF6eIru6IS/ws2BynQWSdGQx/r/7opz2j49KX/sr2fNa7ofz2I5sBspVXWTMyE5 lbZg==
X-Gm-Message-State: AOJu0YxIJb75jGFsGXuAeJPtH1KBvsNhzrP7GR1jOmobjfSvCfVOJJKO r1XSzgmruVQa0VFLO1xk2BmFplaR3nIb0qQkONEdJ2oPsP0=
X-Google-Smtp-Source: AGHT+IFMTXf7zjh+KdqeVbOHZGkbW6MjNZhmcCgENIj6PG8i09WgwZvSbDCq1MLfBfEktlF6WkrTFX5HWaY4BOEeAoY=
X-Received: by 2002:a05:6512:b93:b0:509:cbfa:1c31 with SMTP id b19-20020a0565120b9300b00509cbfa1c31mr1231883lfv.40.1699574614876; Thu, 09 Nov 2023 16:03:34 -0800 (PST)
MIME-Version: 1.0
From: Rory Hewitt <rory.hewitt@gmail.com>
Date: Thu, 09 Nov 2023 16:03:23 -0800
Message-ID: <CAEmMwDyy2hHfAN3gWWyyKRNFDUJ9i9aDgb=ciEcEYrJOFzxcKA@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>, TLS List <tls@ietf.org>, "Hewitt, Rory" <rhewitt=40akamai.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003067fb0609c10d97"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/b1686MIcauI3i0smQs4Jf8OHExs>
Subject: [TLS] The qpack_static_table_version TLS extension (Draft version 02)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 10 Nov 2023 00:03:42 -0000

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 being
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-version-02.html

Significant changes from version-01 are as follows:

1. I changed references to registry "Version" to "Variant" to make it clear
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 which
only use a very small set of headers with known values.

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 significantly
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 and
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 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 being 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 'concerns'
about ALPS, but I'm not clear on what they were or who was concerned - HTTP
WG or TLS WG or both or some other entity?

Finally, I'm still trying to build a test harness to determine whether 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 co-author
credit, for what that's worth :)

Thanks,

Rory