draft-ietf-httpbis-compression-dictionary-00.txt   draft-ietf-httpbis-compression-dictionary-latest.txt 
HTTP Working Group P. Meenan, Ed. HTTP Working Group P. Meenan, Ed.
Internet-Draft Y. Weiss, Ed. Internet-Draft Y. Weiss, Ed.
Intended status: Standards Track Google LLC Intended status: Standards Track Google LLC
Expires: March 14, 2024 September 11, 2023 Expires: June 11, 2024 December 09, 2023
Compression Dictionary Transport Compression Dictionary Transport
draft-ietf-httpbis-compression-dictionary-00 draft-ietf-httpbis-compression-dictionary-latest
Abstract Abstract
This specification defines a mechanism for using designated [HTTP] This specification defines a mechanism for using designated [HTTP]
responses as an external dictionary for future HTTP responses for responses as an external dictionary for future HTTP responses for
compression schemes that support using external dictionaries (e.g., compression schemes that support using external dictionaries (e.g.,
Brotli [RFC7932] and Zstandard [RFC8878]). Brotli [RFC7932] and Zstandard [RFC8878]).
About This Document About This Document
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 14, 2024. This Internet-Draft will expire on June 11, 2024.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Dictionary Negotiation . . . . . . . . . . . . . . . . . . . 3 2. Dictionary Negotiation . . . . . . . . . . . . . . . . . . . 3
2.1. Use-As-Dictionary . . . . . . . . . . . . . . . . . . . . 3 2.1. Use-As-Dictionary . . . . . . . . . . . . . . . . . . . . 3
2.1.1. match . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. match . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2. ttl . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.2. match-search . . . . . . . . . . . . . . . . . . . . 4
2.1.3. type . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.3. match-dest . . . . . . . . . . . . . . . . . . . . . 4
2.1.4. hashes . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.4. ttl . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.5. Examples . . . . . . . . . . . . . . . . . . . . . . 5 2.1.5. id . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Available-Dictionary . . . . . . . . . . . . . . . . . . 5 2.1.6. type . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.7. Examples . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Available-Dictionary . . . . . . . . . . . . . . . . . . 6
2.2.1. Dictionary freshness requirement . . . . . . . . . . 6 2.2.1. Dictionary freshness requirement . . . . . . . . . . 6
2.2.2. Dictionary URL matching . . . . . . . . . . . . . . . 6 2.2.2. Dictionary URL matching . . . . . . . . . . . . . . . 6
2.2.3. Multiple matching dictionaries . . . . . . . . . . . 7 2.2.3. Multiple matching dictionaries . . . . . . . . . . . 7
3. Negotiating the compression algorithm . . . . . . . . . . . . 7 2.3. Dictionary-ID . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 8 2.4. Content-Dictionary . . . . . . . . . . . . . . . . . . . 8
3.2. Content-Encoding . . . . . . . . . . . . . . . . . . . . 8 3. Negotiating the compression algorithm . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 3.1. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 9
4.1. Content Encoding . . . . . . . . . . . . . . . . . . . . 8 3.2. Content-Encoding . . . . . . . . . . . . . . . . . . . . 9
4.2. Header Field Registration . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Compatibility Considerations . . . . . . . . . . . . . . . . 9 4.1. Content Encoding . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4.2. Header Field Registration . . . . . . . . . . . . . . . . 10
6.1. Changing content . . . . . . . . . . . . . . . . . . . . 9 5. Compatibility Considerations . . . . . . . . . . . . . . . . 10
6.2. Reading content . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6.3. Security Mitigations . . . . . . . . . . . . . . . . . . 10 6.1. Changing content . . . . . . . . . . . . . . . . . . . . 10
6.3.1. Cross-origin protection . . . . . . . . . . . . . . . 10 6.2. Reading content . . . . . . . . . . . . . . . . . . . . . 11
6.3.2. Response readability . . . . . . . . . . . . . . . . 10 6.3. Security Mitigations . . . . . . . . . . . . . . . . . . 11
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 6.3.1. Cross-origin protection . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3.2. Response readability . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This specification defines a mechanism for using designated [HTTP] This specification defines a mechanism for using designated [HTTP]
responses as an external dictionary for future HTTP responses for responses as an external dictionary for future HTTP responses for
compression schemes that support using external dictionaries (e.g., compression schemes that support using external dictionaries (e.g.,
Brotli [RFC7932] and Zstandard [RFC8878]). Brotli [RFC7932] and Zstandard [RFC8878]).
This document describes the HTTP headers used for negotiating This document describes the HTTP headers used for negotiating
dictionary usage and registers media types for content encoding dictionary usage and registers media types for content encoding
skipping to change at page 3, line 27 skipping to change at page 3, line 31
This document uses the line folding strategies described in This document uses the line folding strategies described in
[FOLDING]. [FOLDING].
2. Dictionary Negotiation 2. Dictionary Negotiation
2.1. Use-As-Dictionary 2.1. Use-As-Dictionary
When responding to a HTTP Request, a server can advertise that the When responding to a HTTP Request, a server can advertise that the
response can be used as a dictionary for future requests for URLs response can be used as a dictionary for future requests for URLs
that match the pattern specified in the Use-As-Dictionary response that match the rules specified in the Use-As-Dictionary response
header. header.
The Use-As-Dictionary response header is a Structured Field The Use-As-Dictionary response header is a Structured Field
[STRUCTURED-FIELDS] sf-dictionary with values for "match", "ttl", [STRUCTURED-FIELDS] sf-dictionary with values for "match", "match-
"type" and "hashes". search", "match-dest", "ttl", "id", and "type".
2.1.1. match 2.1.1. match
The "match" value of the Use-As-Dictionary header is a sf-string The "match" value of the Use-As-Dictionary header is a sf-string
value that provides an URL-matching pattern for requests where the value that provides the "pathname" of a URLPattern
dictionary can be used. (https://urlpattern.spec.whatwg.org/#dom-urlpatterninit-pathname).
The sf-string is parsed as a URL [URL], and supports absolute URLs as
well as relative URLs. When stored, any relative URLs MUST be
expanded so that only absolute URL patterns are used for matching
against requests.
The match URL supports using * as a wildcard within the match string The "match" is a [URL] path relative to the full request URL of the
for pattern-matching multiple URLs. URLs with a natural * in them dictionary. The request URL for the dictionary itself is used as the
are not directly supported unless they can rely on the behavior of * "baseURL" for constructing the URLPattern
matching an arbitrary string. (https://urlpattern.spec.whatwg.org/) that is used for matching the
dictionary to relevant requests when running Section 2.2.2.
The [Origin] of the URL in the "match" pattern MUST be the same as The URLPattern used for request matching does not support regular
the origin of the request that specifies the "Use-As-Dictionary" expressions (https://urlpattern.spec.whatwg.org/#token-type-regexp)
response and MUST not include a * wildcard. in the "match".
The "match" value is required and MUST be included in the Use-As- The "match" value is required and MUST be included in the Use-As-
Dictionary sf-dictionary for the dictionary to be considered valid. Dictionary sf-dictionary for the dictionary to be considered valid.
2.1.2. ttl 2.1.2. match-search
The "match-search" value of the Use-As-Dictionary header is a sf-
string value that provides the "search" of a URLPattern
(https://urlpattern.spec.whatwg.org/#dom-urlpatterninit-search).
The "match-search" is the match pattern for the searchpart of the
request [URL] and does not support regular expressions.
The "match-search" value is optional and defaults to the asterisk
wildcard token "*".
2.1.3. match-dest
The "match-dest" value of the Use-As-Dictionary header is a sf-string
value that provides a request destination
(https://fetch.spec.whatwg.org/#concept-request-destination).
An empty string for "match-dest" MUST match all destinations.
For clients that do not support request destinations or if the value
of "match-dest" is a value that is not supported by the client then
the client MUST treat it as an empty string and match all
destinations.
The "match-dest" value is optional and defaults to the empty string.
2.1.4. ttl
The "ttl" value of the Use-As-Dictionary header is a sf-integer value The "ttl" value of the Use-As-Dictionary header is a sf-integer value
that provides the time in seconds that the dictionary is valid for that provides the time in seconds that the dictionary is valid for
(time to live). (time to live).
The "ttl" is independent of the cache lifetime of the resource being The "ttl" is independent of the cache lifetime of the resource being
used for the dictionary. If the underlying resource is evicted from used for the dictionary. If the underlying resource is evicted from
cache then it is also removed but this allows for setting an explicit cache then it is also removed but this allows for setting an explicit
time to live for use as a dictionary independent of the underlying time to live for use as a dictionary independent of the underlying
resource in cache. Expired resources can still be useful as resource in cache. Expired resources can still be useful as
dictionaries while they are in cache and can be used for fetching dictionaries while they are in cache and can be used for fetching
updates of the expired resource. It can also be useful to updates of the expired resource. It can also be useful to
artificially limit the life of a dictionary in cases where the artificially limit the life of a dictionary in cases where the
dictionary is updated frequently which can help limit the number of dictionary is updated frequently which can help limit the number of
possible incoming dictionary variations. possible incoming dictionary variations.
The "ttl" value is optional and defaults to 31536000 (1 year). The "ttl" value is optional and defaults to 1209600 (14 days).
2.1.3. type 2.1.5. id
The "id" value of the Use-As-Dictionary header is a sf-string value
that specifies a server identifier for the dictionary. If an "id"
value is present then it MUST be sent to the server in a "Dictionary-
ID" request header when the dictionary is advertised as being
available.
The server identifier MUST be treated as an opaque string by the
client.
The server identifier MUST NOT be relied upon by the server to
guarantee the contents of the dictionary. The dictionary hash MUST
be validated before use.
The "id" value string length (after any decoding) supports up to 1024
characters.
The "id" value is optional.
2.1.6. type
The "type" value of the Use-As-Dictionary header is a sf-string value The "type" value of the Use-As-Dictionary header is a sf-string value
that describes the file format of the supplied dictionary. that describes the file format of the supplied dictionary.
"raw" is the only defined dictionary format which represents an "raw" is the only defined dictionary format which represents an
unformatted blob of bytes suitable for any compression scheme to use. unformatted blob of bytes suitable for any compression scheme to use.
If a client receives a dictionary with a type that it does not If a client receives a dictionary with a type that it does not
understand, it MUST NOT use the dictionary. understand, it MUST NOT use the dictionary.
The "type" value is optional and defaults to "raw". The "type" value is optional and defaults to "raw".
2.1.4. hashes 2.1.7. Examples
The "hashes" value of the Use-As-Dictionary header is a inner-list
value that provides a list of supported hash algorithms in order of
server preference.
The dictionaries are identified by the hash of their contents and
this value allows for negotiation of the algorithm to use.
The "hashes" value is optional and defaults to (sha-256).
2.1.5. Examples
2.1.5.1. Path Prefix 2.1.7.1. Path Prefix
A response that contained a response header: A response that contained a response header:
NOTE: '\' line wrapping per RFC 8792 NOTE: '\' line wrapping per RFC 8792
Use-As-Dictionary: \ Use-As-Dictionary: \
match="/product/*", ttl=604800, hashes=(sha-256 sha-512) match="/product/*", match-dest="document", ttl=604800
Would specify matching any URL with a path prefix of /product/ on the Would specify matching any document request for a URL with a path
same [Origin] as the original request, expiring as a dictionary in 7 prefix of /product/ on the same [Origin] as the original request, and
days independent of the cache lifetime of the resource, and advertise expiring as a dictionary in 7 days independent of the cache lifetime
support for both sha-256 and sha-512 hash algorithms. of the resource.
2.1.5.2. Versioned Directories 2.1.7.2. Versioned Directories
A response that contained a response header: A response that contained a response header:
Use-As-Dictionary: match="/app/*/main.js" Use-As-Dictionary: match="/app/*/main.js"
Would match main.js in any directory under /app/, expiring as a Would match main.js in any directory under /app/ and expiring as a
dictionary in one year and support using the sha-256 hash algorithm. dictionary in one year.
2.2. Available-Dictionary 2.2. Available-Dictionary
When a HTTP client makes a request for a resource for which it has an When a HTTP client makes a request for a resource for which it has an
appropriate dictionary, it can add a "Available-Dictionary" request appropriate dictionary, it can add a "Available-Dictionary" request
header to the request to indicate to the server that it has a header to the request to indicate to the server that it has a
dictionary available to use for compression. dictionary available to use for compression.
The "Available-Dictionary" request header is a lowercase The "Available-Dictionary" request header is a Structured Field
Base16-encoded [RFC4648] hash of the contents of a single available [STRUCTURED-FIELDS] sf-binary [SHA-256] hash of the contents of a
dictionary calculated using one of the algorithms advertised as being single available dictionary.
supported by the server.
Its syntax is defined by the following [ABNF]:
Available-Dictionary = hvalue
hvalue = 1*hchar
hchar = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
The client MUST only send a single "Available-Dictionary" request The client MUST only send a single "Available-Dictionary" request
header with a single hash value for the best available match that it header with a single hash value for the best available match that it
has available. has available.
For example: For example:
NOTE: '\' line wrapping per RFC 8792 Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
Available-Dictionary: \
a591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b57b277d9ad9f146e
2.2.1. Dictionary freshness requirement 2.2.1. Dictionary freshness requirement
To be considered as a match, the dictionary must not yet be expired To be considered as a match, the dictionary must not yet be expired
as a dictionary. When iterating through dictionaries looking for a as a dictionary. When iterating through dictionaries looking for a
match, the expiration time of the dictionary is calculated by taking match, the expiration time of the dictionary is calculated by taking
the last time the dictionary was written and adding the "ttl" seconds the last time the dictionary was fetched and adding the "ttl" seconds
from the "Use-As-Dictionary" response. If the current time is beyond from the "Use-As-Dictionary" response. If the current time is beyond
the expiration time of the dictionary, it MUST be ignored. the expiration time of the dictionary, it MUST be ignored.
2.2.2. Dictionary URL matching 2.2.2. Dictionary URL matching
When a dictionary is stored as a result of a "Use-As-Dictionary" When a dictionary is stored as a result of a "Use-As-Dictionary"
directive, it includes a "match" string with the URL pattern of directive, it includes "match", "match-search" and "match-dest"
request URLs that the dictionary can be used for. strings that are used to match an outgoing request from a client to
the available dictionaries.
When comparing request URLs to the available dictionary match To see if an outbound request matches a given dictionary, the
patterns, the comparison should account for the * wildcard when following algorithm will return TRUE for a successful match and FALSE
matching against request URLs. This can be accomplished with the for no-match:
following algorithm which returns TRUE for a successful match and
FALSE for no-match:
1. Let MATCH represent the absolute URL pattern from the "match" 1. If the current client supports request destinations:
value for the given dictionary.
2. LET URL represent the request URL being checked. * Let DEST be the value of "match-dest" for the given
dictionary.
3. If there are no * characters in MATCH: * Let REQUEST_DEST be the value of the destination for the
current request.
* If the MATCH and URL strings are identical, return TRUE. * If DEST is not an empty string and If DEST and REQUEST_DEST
are not the same value, return FALSE
* Else, return FALSE. 2. Let PATH be the value of "match" for the given dictionary.
4. If there is a single * character in MATCH and it is at the end of 3. Let SEARCH be the value of "match-search" for the given
the string: dictionary.
* If the MATCH string is identical to the start of the URL 4. Let BASEURL be the request URL of the given dictionary.
string, return TRUE.
* Else, return FALSE. 5. Let PATTERN be a URLPattern constructed by setting pathname=PATH,
search=SEARCH, baseURL=BASEURL
(https://urlpattern.spec.whatwg.org/).
5. Split the MATCH string by the * character into an array of 6. LET URL represent the request URL being checked.
MATCHES (excluding the * deliminator from the individual
entries).
6. If there is not a * character at the end of MATCH: 7. Return the result of running the URLPattern "match" algorithm
(https://urlpattern.spec.whatwg.org/#match)
* Pop the last entry in MATCHES from the end of the array into 2.2.3. Multiple matching dictionaries
PATTERN.
* If PATTERN is identical to the end of the URL string, remove When there are multiple dictionaries that match a given request URL,
the end of the URL string to the beginning of the match to the client MUST pick a single dictionary using the following rules:
PATTERN. 1. For clients that support request destinations, a dictionary that
specifies and matches a "match-dest" takes precedence over a match
that does not use a destination. 1. Given equivalent destination
precedence, the dictionary with the longest "match" takes precedence.
1. Given equivalent destination and path precedence, the dictionary
with the longest "match-search" takes precedence. 1. Given
equivalent destination, path and search precedence, the most recently
fetched dictionary takes precedence.
* Else, return FALSE. 2.3. Dictionary-ID
7. Pop the first entry in MATCHES from the front of the array into When a HTTP client makes a request for a resource for which it has an
PATTERN. appropriate dictionary and the dictionary was stored with a server-
provided "id" in the Use-As-Dictionary response then the client MUST
echo the stored "id" in a "Dictionary-ID" request header.
* If PATTERN is not identical to the start of the URL string, The "Dictionary-ID" request header is a Structured Field
return FALSE. [STRUCTURED-FIELDS] sf-string of up to 1024 characters (after any
decoding) and MUST be identical to the server-provided "id".
8. Pop each entry off of the front of the MATCHES array into For example:
PATTERN. For each PATTERN, in order:
* Search for the first match of PATTERN in URL, starting from Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
the position of the end of the previous match. Dictionary-ID: "/v1/main.js 33a64df551425fcc55e4d42a148795d9f25f89d4"
* If no match is found, return FALSE. 2.4. Content-Dictionary
9. Return TRUE. When a HTTP server responds with a resource that is encoded with a
dictionary the server MUST send the hash of the dictionary that was
used in the "Content-Dictionary" response header.
2.2.3. Multiple matching dictionaries The "Content-Dictionary" response header is a Structured Field
[STRUCTURED-FIELDS] sf-dictionary [SHA-256] hash of the contents of
the dictionary that was used to encode the response.
When there are multiple dictionaries that match a given request URL, If the HTTP response contains a "Content-Dictionary" response header
the client MUST pick the dictionary with the longest match pattern with the hash of a dictionary that the client does not have available
string length. then the client cannot decode or use the HTTP response.
For example:
Content-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
3. Negotiating the compression algorithm 3. Negotiating the compression algorithm
When a compression dictionary is available for use for a given When a compression dictionary is available for use for a given
request, the algorithm to be used is negotiated through the regular request, the algorithm to be used is negotiated through the regular
mechanism for negotiating content encoding in HTTP. mechanism for negotiating content encoding in HTTP.
This document introduces two new content encoding algorithms: This document introduces two new content encoding algorithms:
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
skipping to change at page 9, line 27 skipping to change at page 10, line 27
IANA is asked to update the "Hypertext Transfer Protocol (HTTP) Field IANA is asked to update the "Hypertext Transfer Protocol (HTTP) Field
Name Registry" registry ([HTTP]) according to the table below: Name Registry" registry ([HTTP]) according to the table below:
+----------------------+-----------+------------------------------+ +----------------------+-----------+------------------------------+
| Field Name | Status | Reference | | Field Name | Status | Reference |
+----------------------+-----------+------------------------------+ +----------------------+-----------+------------------------------+
| Use-As-Dictionary | permanent | Section 2.1 of this document | | Use-As-Dictionary | permanent | Section 2.1 of this document |
| | | | | | | |
| Available-Dictionary | permanent | Section 2.2 of this document | | Available-Dictionary | permanent | Section 2.2 of this document |
| | | |
| Dictionary-ID | permanent | Section 2.3 of this document |
| | | |
| Content-Dictionary | permanent | Section 2.4 of this document |
+----------------------+-----------+------------------------------+ +----------------------+-----------+------------------------------+
5. Compatibility Considerations 5. Compatibility Considerations
To minimize the risk of middle-boxes incorrectly processing To minimize the risk of middle-boxes incorrectly processing
dictionary-compressed responses, compression dictionary transport dictionary-compressed responses, compression dictionary transport
MUST only be used in secure contexts (HTTPS). MUST only be used in secure contexts (HTTPS).
6. Security Considerations 6. Security Considerations
The security considerations for Brotli [RFC7932] and Zstandard The security considerations for Brotli [RFC7932] and Zstandard
[RFC8878] apply to the dictionary-based versions of the respective [RFC8878] apply to the dictionary-based versions of the respective
algorithms. algorithms.
6.1. Changing content 6.1. Changing content
The dictionary must be treated with the same security precautions as The dictionary must be treated with the same security precautions as
the content, because a change to the dictionary can result in a the content, because a change to the dictionary can result in a
change to the decompressed content. change to the decompressed content.
The dictionary is validated using a SHA-256 hash of the content to
make sure that the client and server are both using the same
dictionary. The strength of the SHA-256 hash algorithm isn't
explicitly needed to counter attacks since the dictionary is being
served from the same origin as the content. That said, if a weakness
is discovered in SHA-256 and it is determined that the dictionary
negotiation should use a different hash algorithm, the "Use-As-
Dictionary" response header can be extended to specify a different
algorithm and the server would just ignore any "Available-Dictionary"
requests that do not use the updated hash.
6.2. Reading content 6.2. Reading content
The CRIME attack shows that it's a bad idea to compress data from The CRIME attack shows that it's a bad idea to compress data from
mixed (e.g. public and private) sources -- the data sources include mixed (e.g. public and private) sources -- the data sources include
not only the compressed data but also the dictionaries. For example, not only the compressed data but also the dictionaries. For example,
if you compress secret cookies using a public-data-only dictionary, if you compress secret cookies using a public-data-only dictionary,
you still leak information about the cookies. you still leak information about the cookies.
Not only can the dictionary reveal information about the compressed Not only can the dictionary reveal information about the compressed
data, but vice versa, data compressed with the dictionary can reveal data, but vice versa, data compressed with the dictionary can reveal
skipping to change at page 10, line 22 skipping to change at page 11, line 36
information about the compressed data. information about the compressed data.
6.3. Security Mitigations 6.3. Security Mitigations
If any of the mitigations do not pass, the client MUST drop the If any of the mitigations do not pass, the client MUST drop the
response and return an error. response and return an error.
6.3.1. Cross-origin protection 6.3.1. Cross-origin protection
To make sure that a dictionary can only impact content from the same To make sure that a dictionary can only impact content from the same
origin where the dictionary was served, the "match" pattern used for origin where the dictionary was served, the URLPattern used for
matching a dictionary to requests MUST be for the same origin that matching a dictionary to requests is guaranteed to be for the same
the dictionary is served from. origin that the dictionary is served from.
6.3.2. Response readability 6.3.2. Response readability
For clients, like web browsers, that provide additional protection For clients, like web browsers, that provide additional protection
against the readability of the payload of a response and against user against the readability of the payload of a response and against user
tracking, additional protections MUST be taken to make sure that the tracking, additional protections MUST be taken to make sure that the
use of dictionary-based compression does not reveal information that use of dictionary-based compression does not reveal information that
would not otherwise be available. would not otherwise be available.
In these cases, dictionary compression MUST only be used when both In these cases, dictionary compression MUST only be used when both
skipping to change at page 13, line 30 skipping to change at page 14, line 45
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[Origin] Barth, A., "The Web Origin Concept", RFC 6454, [Origin] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011, DOI 10.17487/RFC6454, December 2011,
<https://www.rfc-editor.org/info/rfc6454>. <https://www.rfc-editor.org/info/rfc6454>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC7932] Alakuijala, J. and Z. Szabadka, "Brotli Compressed Data [RFC7932] Alakuijala, J. and Z. Szabadka, "Brotli Compressed Data
Format", RFC 7932, DOI 10.17487/RFC7932, July 2016, Format", RFC 7932, DOI 10.17487/RFC7932, July 2016,
<https://www.rfc-editor.org/info/rfc7932>. <https://www.rfc-editor.org/info/rfc7932>.
[RFC8878] Collet, Y. and M. Kucherawy, Ed., "Zstandard Compression [RFC8878] Collet, Y. and M. Kucherawy, Ed., "Zstandard Compression
and the 'application/zstd' Media Type", RFC 8878, and the 'application/zstd' Media Type", RFC 8878,
DOI 10.17487/RFC8878, February 2021, DOI 10.17487/RFC8878, February 2021,
<https://www.rfc-editor.org/info/rfc8878>. <https://www.rfc-editor.org/info/rfc8878>.
[SHA-256] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[STRUCTURED-FIELDS] [STRUCTURED-FIELDS]
Nottingham, M. and P. Kamp, "Structured Field Values for Nottingham, M. and P. Kamp, "Structured Field Values for
HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
<https://www.rfc-editor.org/info/rfc8941>. <https://www.rfc-editor.org/info/rfc8941>.
[URL] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [URL] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
 End of changes. 51 change blocks. 
131 lines changed or deleted 190 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/