draft-ietf-httpbis-compression-dictionary-04.txt		draft-ietf-httpbis-compression-dictionary-latest.txt
	HTTP Working Group P. Meenan, Ed.		HTTP Working Group P. Meenan, Ed.
	Internet-Draft Google LLC		Internet-Draft Google LLC
	Intended status: Standards Track Y. Weiss, Ed.		Intended status: Standards Track Y. Weiss, Ed.
	Expires: November 21, 2024 Shopify Inc		Expires: November 25, 2024 Shopify Inc
	May 20, 2024		May 24, 2024
	Compression Dictionary Transport		Compression Dictionary Transport
	draft-ietf-httpbis-compression-dictionary-04		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 (RFC 7932) and Zstandard (RFC 8878)).		Brotli (RFC 7932) and Zstandard (RFC 8878)).
	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 November 21, 2024.		This Internet-Draft will expire on November 25, 2024.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2024 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 46 ¶		skipping to change at page 2, line 46 ¶
	2.3. Dictionary-ID . . . . . . . . . . . . . . . . . . . . . . 7		2.3. Dictionary-ID . . . . . . . . . . . . . . . . . . . . . . 7
	3. The 'compression-dictionary' Link Relation Type . . . . . . . 8		3. The 'compression-dictionary' Link Relation Type . . . . . . . 8
	4. Dictionary-Compressed Brotli . . . . . . . . . . . . . . . . 8		4. Dictionary-Compressed Brotli . . . . . . . . . . . . . . . . 8
	5. Dictionary-Compressed Zstandard . . . . . . . . . . . . . . . 9		5. Dictionary-Compressed Zstandard . . . . . . . . . . . . . . . 9
	6. Negotiating the content encoding . . . . . . . . . . . . . . 10		6. Negotiating the content encoding . . . . . . . . . . . . . . 10
	6.1. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 10		6.1. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 10
	6.2. Content-Encoding . . . . . . . . . . . . . . . . . . . . 10		6.2. Content-Encoding . . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	7.1. Content Encoding . . . . . . . . . . . . . . . . . . . . 11		7.1. Content Encoding . . . . . . . . . . . . . . . . . . . . 11
	7.2. Header Field Registration . . . . . . . . . . . . . . . . 11		7.2. Header Field Registration . . . . . . . . . . . . . . . . 11
	7.3. Link Relation Registration . . . . . . . . . . . . . . . 11		7.3. Link Relation Registration . . . . . . . . . . . . . . . 12
	8. Compatibility Considerations . . . . . . . . . . . . . . . . 12		8. Compatibility Considerations . . . . . . . . . . . . . . . . 12
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 12		9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	9.1. Changing content . . . . . . . . . . . . . . . . . . . . 12		9.1. Changing content . . . . . . . . . . . . . . . . . . . . 12
	9.2. Reading content . . . . . . . . . . . . . . . . . . . . . 12		9.2. Reading content . . . . . . . . . . . . . . . . . . . . . 12
	9.3. Security Mitigations . . . . . . . . . . . . . . . . . . 13		9.3. Security Mitigations . . . . . . . . . . . . . . . . . . 13
	9.3.1. Cross-origin protection . . . . . . . . . . . . . . . 13		9.3.1. Cross-origin protection . . . . . . . . . . . . . . . 13
	9.3.2. Response readability . . . . . . . . . . . . . . . . 13		9.3.2. Response readability . . . . . . . . . . . . . . . . 13
	10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15		9.3.3. Server Responsibility . . . . . . . . . . . . . . . . 13
			10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	11.1. Normative References . . . . . . . . . . . . . . . . . . 16		11.1. Normative References . . . . . . . . . . . . . . . . . . 15
	11.2. Informative References . . . . . . . . . . . . . . . . . 17		11.2. Informative References . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	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 10, line 29 ¶		skipping to change at page 10, line 29 ¶
	request, the encoding to be used is negotiated through the regular		request, the encoding to be used is negotiated through the regular
	mechanism for negotiating content encoding in HTTP through the		mechanism for negotiating content encoding in HTTP through the
	"Accept-Encoding" request header and "Content-Encoding" response		"Accept-Encoding" request header and "Content-Encoding" response
	header.		header.
	The dictionary to use is negotiated separately and advertised in the		The dictionary to use is negotiated separately and advertised in the
	"Available-Dictionary" request header.		"Available-Dictionary" request header.
	6.1. Accept-Encoding		6.1. Accept-Encoding
	The client adds the content encodings that it supports to the		When a dictionary is available for use on a given request, and the
	"Accept-Encoding" request header. e.g.:		client chooses to make dictionary-based content-encoding available,
			the client adds the dictionary-aware content encodings that it
			supports to the "Accept-Encoding" request header. e.g.:
	Accept-Encoding: gzip, deflate, br, zstd, dcb, dcz		Accept-Encoding: gzip, deflate, br, zstd, dcb, dcz
			When a client does not have a stored dictionary that matches the
			request, or chooses not to use one for the request, the client MUST
			NOT send its dictionary-aware content-encodings in the "Accept-
			Encoding" request header.
	6.2. Content-Encoding		6.2. Content-Encoding
	If a server supports one of the dictionary encodings advertised by		If a server supports one of the dictionary encodings advertised by
	the client and chooses to compress the content of the response using		the client and chooses to compress the content of the response using
	the dictionary that the client has advertised then it sets the		the dictionary that the client has advertised then it sets the
	"Content-Encoding" response header to the appropriate value for the		"Content-Encoding" response header to the appropriate value for the
	algorithm selected. e.g.:		algorithm selected. e.g.:
	Content-Encoding: dcb		Content-Encoding: dcb
	If the response is cacheable, it MUST include a "Vary" header to		If the response is cacheable, it MUST include a "Vary" header to
	prevent caches serving dictionary-compressed resources to clients		prevent caches serving dictionary-compressed resources to clients
	that don't support them or serving the response compressed with the		that don't support them or serving the response compressed with the
	wrong dictionary:		wrong dictionary:
	Vary: accept-encoding, available-dictionary		Vary: accept-encoding, available-dictionary
	7. IANA Considerations		7. IANA Considerations
	7.1. Content Encoding		7.1. Content Encoding
	skipping to change at page 13, line 34 ¶		skipping to change at page 13, line 41 ¶
	In these cases, dictionary compression MUST only be used when both		In these cases, dictionary compression MUST only be used when both
	the dictionary and the compressed response are fully readable by the		the dictionary and the compressed response are fully readable by the
	client.		client.
	In browser terms, that means that both are either same-origin to the		In browser terms, that means that both are either same-origin to the
	context they are being fetched from or that the response is cross-		context they are being fetched from or that the response is cross-
	origin and passes the CORS check		origin and passes the CORS check
	(https://fetch.spec.whatwg.org/#cors-check).		(https://fetch.spec.whatwg.org/#cors-check).
	9.3.2.1. Same-Origin		9.3.3. Server Responsibility
	On the client-side, same-origin determination is defined in the fetch
	spec (https://html.spec.whatwg.org/multipage/browsers.html#origin).
	On the server-side, a request with a "Sec-Fetch-Site:" request header
	with a value of "same-origin" is to be considered a same-origin
	request.
	o For any request that is same-origin:
	* Response MAY be used as a dictionary.
	* Response MAY be compressed by an available dictionary.
	9.3.2.2. Cross-Origin
	For requests that are not same-origin (Section 9.3.2.1), the "mode"
	of the request can be used to determine the readability of the
	response.
	For clients that conform to the fetch spec, the mode of the request
	is stored in the RequestMode attribute of the request
	(https://fetch.spec.whatwg.org/#requestmode).
	For servers responding to clients that expose the request mode
	information, the value of the mode is sent in the "Sec-Fetch-Mode"
	request header.
	If a "Sec-Fetch-Mode" request header is not present, the server
	SHOULD allow for the dictionary compression to be used.
	1. If the mode is "navigate" or "same-origin":
	* Response MAY be used as a dictionary.
	* Response MAY be compressed by an available dictionary.
	2. If the mode is "cors":
	* For clients, apply the CORS check from the fetch spec
	(https://fetch.spec.whatwg.org/#cors-check) which includes
	credentials checking restrictions that may not be possible to
	check on the server.
	+ If the CORS check passes:
	- Response MAY be used as a dictionary.
	- Response MAY be compressed by an available dictionary.
	+ Else:
	- Response MUST NOT be used as a dictionary.
	- Response MUST NOT be compressed by an available
	dictionary.
	* For servers:
	+ If the response does not include an "Access-Control-Allow-
	Origin" response header:
	- Response MUST NOT be used as a dictionary.
	- Response MUST NOT be compressed by an available		As with any usage of compressed content in a secure context, a
	dictionary.		potential timing attack exists if the attacker can control any part
			of the dictionary, or if it can read the dictionary and control any
			part of the content being compressed, while performing multiple
			requests that vary the dictionary or injected content. Under such an
			attack, the changing size or processing time of the response reveals
			information about the content, which might be sufficient to read the
			supposedly secure response.
	+ If the request does not include an "Origin" request header:		In general, a server can mitigate such attacks by preventing
			variations per request, as in preventing active use of multiple
			dictionaries for the same content, disabling compression when any
			portion of the content comes from uncontrolled sources, and securing
			access and control over the dictionary content in the same way as the
			response content. In addition, the following requirements on a
			server are intended to disable dictionary-aware compression when the
			client provides CORS request header fields that indicate a cross-
			origin request context.
	- Response MUST NOT be used as a dictionary.		The following algorithm will return FALSE for cross-origin requests
			where precautions such as not using dictionary-based compression
			should be considered:
	- Response MUST NOT be compressed by an available		1. If there is no "Sec-Fetch-Site" request header then return TRUE.
	dictionary.
	+ If the value of the "Access-Control-Allow-Origin" response		2. if the value of the "Sec-Fetch-Site" request header is "same-
	header is "*":		origin" then return TRUE.
	- Response MAY be used as a dictionary.		3. If there is no "Sec-Fetch-Mode" request header then return TRUE.
	- Response MAY be compressed by an available dictionary.		4. If the value of the "Sec-Fetch-Mode" request header is "navigate"
			or "same-origin" then return TRUE.
	+ If the value of the "Access-Control-Allow-Origin" response		5. If the value of the "Sec-Fetch-Mode" request header is "cors":
	header matches the value of the "Origin" request header:
	- Response MAY be used as a dictionary.		* If the response does not include an "Access-Control-Allow-
			Origin" response header then return FALSE.
	- Response MAY be compressed by an available dictionary.		* If the request does not include an "Origin" request header
			then return FALSE.
	3. If the mode is any other value (including "no-cors"):		* If the value of the "Access-Control-Allow-Origin" response
			header is "*" then return TRUE.
	* Response MUST NOT be used as a dictionary.		* If the value of the "Access-Control-Allow-Origin" response
			header matches the value of the "Origin" request header then
			return TRUE.
	* Response MUST NOT be compressed by an available dictionary.		6. return FALSE.
	10. Privacy Considerations		10. Privacy Considerations
	Since dictionaries are advertised in future requests using the hash		Since dictionaries are advertised in future requests using the hash
	of the content of the dictionary, it is possible to abuse the		of the content of the dictionary, it is possible to abuse the
	dictionary to turn it into a tracking cookie.		dictionary to turn it into a tracking cookie.
	To mitigate any additional tracking concerns, clients MUST treat		To mitigate any additional tracking concerns, clients MUST treat
	dictionaries in the same way that they treat cookies. This includes		dictionaries in the same way that they treat cookies. This includes
	partitioning the storage as cookies are partitioned as well as		partitioning the storage as cookies are partitioned as well as
End of changes. 23 change blocks.
	93 lines changed or deleted		57 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/