The qpack_static_table_version TLS extension
draft-hewitt-ietf-qpack-static-table-version-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Rory Hewitt | ||
| Last updated | 2023-09-25 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hewitt-ietf-qpack-static-table-version-00
Internet Engineering Task Force R. Hewitt
Internet-Draft Akamai Technologies Inc.
Intended status: Informational 25 September 2023
Expires: 28 March 2024
The qpack_static_table_version TLS extension
draft-hewitt-ietf-qpack-static-table-version-00
Abstract
This document specifies a new "qpack_static_table_version" TLS
extension to enable clients and servers to agree upon the version of
the HTTP/3 QPACK Static Table to use for communications between them.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 March 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Hewitt Expires 28 March 2024 [Page 1]
Internet-Draft QSTV TLS extension September 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. QPACK Static Table Background . . . . . . . . . . . . . . . . 3
3. QPACK Static Table Additions . . . . . . . . . . . . . . . . 4
4. The qpack_static_table_version TLS extension . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
HTTP/3 uses QPACK [RFC9204] for compression of the header and trailer
sections.
QPACK reuses core concepts from the HPACK algorithm used for HTTP/2,
but as noted in its design "[...]is redesigned to allow correctness
in the presence of out-of-order delivery, with flexibility for
implementations to balance between resilience against head-of-line
blocking and optimal compression ratio."
A core feature of QPACK is the use of a 'static table' which contains
a predefined list of frequently-used field lines, each of which is
identified by a unique, unchanging index in the table, enabling
excellent compression of these field lines. Each entry in the static
table may contain a field name or a field name/value combination.
Less frequently-used fields or field name/value combinations are
passed in the QPACK 'dynamic table'. Because of the optimal
compression, defining field lines in the static table is
significantly desirable over passing them in the dynamic table.
When the static table was originally defined, the field line entries
it contained were calculated by determining the relative frequency
with which each field line was found in a representative sampling of
web traffic. However, as new HTTP fields become more frequently-used
over time, it makes sense that they be added as additional entries to
the static table to retain the high level of compression.
Hewitt Expires 28 March 2024 [Page 2]
Internet-Draft QSTV TLS extension September 2023
When clients and servers communicate using HTTP/3, they each need to
be aware of how many static table entries the other is using, so
there is no mismatch where one refers to a static table entry that
the other does not recognize. As a result, clients and servers must
agree upon the size of the static table they will both use. Because
the size of the static table must be known prior to any HTTP requests
passing between the client and server, this information must be
passed during the TLS handshake.
This specification defines a new TLS extension which can be passed by
both client and server to identify the version (size) of the static
table that they will both use.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The following terms are used in this document:
* *HTTP fields*: Metadata sent as part of an HTTP message. The term
encompasses both header and trailer fields. Colloquially, the
term "headers" has often been used to refer to HTTP header fields
and trailer fields; this document uses "fields" for generality.
* *HTTP field line*: A name-value pair sent as part of an HTTP field
section. See Sections 6.3 and 6.5 of [RFC9110].
* *HTTP field value*: Data associated with a field name, composed
from all field line values with that field name in that section,
concatenated together with comma separators.
Note that QPACK is a name, not an abbreviation.
2. QPACK Static Table Background
The original QPACK static table [RFC9204] contains 99 entries
(starting at entry 0, ending at entry 98), as follows:
Hewitt Expires 28 March 2024 [Page 3]
Internet-Draft QSTV TLS extension September 2023
+==========+==============================+===================+
| Entry | Value | Notes |
+==========+==============================+===================+
| 0 (first | :authority | Field name only |
| entry) | | |
+----------+------------------------------+-------------------+
| 1 | :path / | Field name and |
| | | value combination |
+----------+------------------------------+-------------------+
| 2 | Age 0 | Field name and |
| | | value combination |
+----------+------------------------------+-------------------+
| ...2 - 97... |
+----------+------------------------------+-------------------+
| 98 (last | x-frame-options sameorigin | Field name and |
| entry) | | value combination |
+----------+------------------------------+-------------------+
Table 1
The table was generated by analyzing actual Internet traffic in 2018
and including the most common header fields, after filtering out some
unsupported and non-standard values. Due to this methodology, some
of the entries may be inconsistent or appear multiple times with
similar but not identical values. The order of the entries is
optimized to encode the most common header fields with the smallest
number of bytes.
3. QPACK Static Table Additions
Over time, the IANA will re-sample actual internet traffic and as new
field names or field name/value combinations become more prevalent,
they will be appended as new entries to the static table and a new
version of the static table will be published by IANA.
To maintain backwards-compatibility, new static table entries MUST be
appended to the end of the current published version of the static
table. Once added, entries MUST NOT be removed from a published
version of the static table. As new versions of the static table are
published, they can be implemented by both clients and servers. It
is assumed that clients and servers will support only a single
version of the static table.
4. The qpack_static_table_version TLS extension
The *qpack_static_table_version* TLS extension is an integer value
which represents the number of entries in the static table supported
by the sender.
Hewitt Expires 28 March 2024 [Page 4]
Internet-Draft QSTV TLS extension September 2023
The extension_data for the qpack_static_table_version extension is
*StaticTableLength*, described below using the syntax defined in
[RFC8446]:
struct {
uint8 StaticTableLength;
} QSTVExtension;
Figure 1
The *default value* of the qpack_static_table_version extension is
*99* - the size of the original QPACK static table.
The qpack_static_table_version extension has a minimum allowed value
equal to the default value. Any value lower than the minimum allowed
value, including a negative value, is invalid.
The qpack_static_table_version extension is OPTIONAL and MAY be
passed by a client to a server in the ClientHello, to indicate the
version of the static table that the client supports - that is, the
number of static table entries that the client supports. If the
qpack_static_table_version extension is not present in the
ClientHello, the server MUST assume that the client is using the
default value.
If the ClientHello includes the qpack_static_table_version extension,
the server MAY respond in the ServerHello with its own version of the
static table.
If either the ClientHello or the ServerHello do not include the
qpack_static_table_version extension, or if an invalid value is
specified, then both client and server must fall back to use the
default value.
If both the client and the server pass the qpack_static_table_version
extension, the lower version MUST be used by both client and server,
thus ensuring that both client and server only reference entries in
their static table up to the shared lowest version number.
Sample pseudocode processing:
Hewitt Expires 28 March 2024 [Page 5]
Internet-Draft QSTV TLS extension September 2023
Initialize variable C to supported StaticTableLength value
Include qpack_static_table_version with value C in ClientHello
if (ServerHello does not contain qpack_static_table_version) {
set C to default value
} else {
save qpack_static_table_version from ServerHello as S
if (S is invalid) {
set C to default value
} else if (S < C) {
set C to value of S
}
}
Use C for static table index processing
Figure 2: Client processing
Initialize variable S to supported StaticTableLength value
if (ClientHello does not contain qpack_static_table_version) {
set S to default value
} else {
save qpack_static_table_version from ClientHello as C
if (C is invalid) {
set S to default value
} else if (C < S) {
set S to value of C
}
Include qpack_static_table_version with value S in ServerHello
}
Use S for static table index processing
Figure 3: Server processing
Examples (assuming that multiple versions, including versions 114 and
126, have been published by IANA):
Hewitt Expires 28 March 2024 [Page 6]
Internet-Draft QSTV TLS extension September 2023
+==============+==============+=============+
| Client value | Server value | Value used |
+==============+==============+=============+
| empty | empty | Version 99 |
+--------------+--------------+-------------+
| empty | 114 | Version 99 |
+--------------+--------------+-------------+
| 114 | empty | Version 99 |
+--------------+--------------+-------------+
| 114 | 126 | Version 114 |
+--------------+--------------+-------------+
| 126 | 114 | Version 114 |
+--------------+--------------+-------------+
Table 2
5. IANA Considerations
This memo requests that IANA, on an ongoing basis (suggested once per
year), performs an analysis of a representative sample of web traffic
to determine whether any fields or field/value combinations not
currently present in the latest published version of the static table
are found more frequently in HTTP/3 web traffic requests than the
last entry in the current version of the static table.
In that case, these fields and field/value combinations should be
appended as entries to the static table and a new version of the
static table published.
This publishing by IANA will ensure that all clients and servers that
wish to use a more recent version of the static table can be sure
that the new entries are added in the same order for both client and
server.
6. Security Considerations
This document should not affect the security of the Internet.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Hewitt Expires 28 March 2024 [Page 7]
Internet-Draft QSTV TLS extension September 2023
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9204] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:
Field Compression for HTTP/3", RFC 9204,
DOI 10.17487/RFC9204, June 2022,
<https://www.rfc-editor.org/info/rfc9204>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
Acknowledgements
Many thanks to Rich Salz and Mike Bishop at Akamai for their
invaluable help.
Author's Address
Rory Hewitt
Akamai Technologies Inc.
Email: rhewitt@akamai.com
Hewitt Expires 28 March 2024 [Page 8]