< draft-ietf-httpbis-cache-header-04.txt		draft-ietf-httpbis-cache-header-05.txt >
	HTTP M. Nottingham		HTTP M. Nottingham
	Internet-Draft Fastly		Internet-Draft Fastly
	Intended status: Standards Track August 5, 2020		Intended status: Standards Track August 11, 2020
	Expires: February 6, 2021		Expires: February 12, 2021
	The Cache-Status HTTP Response Header Field		The Cache-Status HTTP Response Header Field
	draft-ietf-httpbis-cache-header-04		draft-ietf-httpbis-cache-header-05
	Abstract		Abstract
	To aid debugging, HTTP caches often append header fields to a		To aid debugging, HTTP caches often append header fields to a
	response explaining how they handled the request. This specification		response explaining how they handled the request. This specification
	codifies that practice and updates it to align with HTTP's current		codifies that practice and updates it to align with HTTP's current
	caching model.		caching model.
	Note to Readers		Note to Readers
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	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 February 6, 2021.		This Internet-Draft will expire on February 12, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 3, line 32 ¶		skipping to change at page 3, line 32 ¶
	Cache-Status = sf-list		Cache-Status = sf-list
	Each member of the list represents a cache that has handled the		Each member of the list represents a cache that has handled the
	request. The first member of the list represents the cache closest		request. The first member of the list represents the cache closest
	to the origin server, and the last member of the list represents the		to the origin server, and the last member of the list represents the
	cache closest to the client (possibly including the user agent's		cache closest to the client (possibly including the user agent's
	cache itself, if it chooses to append a value).		cache itself, if it chooses to append a value).
	Caches determine when it is appropriate to add the Cache-Status		Caches determine when it is appropriate to add the Cache-Status
	header field to a response. Some might decide to add it to all		header field to a response. Some might add it to all responses,
	responses, whereas others might only do so when specifically		whereas others might only do so when specifically configured to, or
	configured to, or when the request contains a header that activates a		when the request contains a header that activates a debugging mode.
	debugging mode.
	When adding a value to the Cache-Status header field, caches SHOULD		When adding a value to the Cache-Status header field, caches SHOULD
	preserve the existing contents of the header field, to allow		preserve the existing contents of the header field, to allow
	debugging of the entire chain of caches handling the request.		debugging of the entire chain of caches handling the request.
	Each list member identifies the cache that inserted that value, and		Each list member identifies the cache that inserted that value, and
	MUST be a String or Token. Depending on the deployment, this might		MUST be a String or Token. Depending on the deployment, this might
	be a product or service name (e.g., ExampleCache or "Example CDN"), a		be a product or service name (e.g., ExampleCache or "Example CDN"), a
	hostname ("cache-3.example.com"), and IP address, or a generated		hostname ("cache-3.example.com"), and IP address, or a generated
	string.		string.
	skipping to change at page 4, line 17 ¶		skipping to change at page 4, line 17 ¶
	fwd-status = sf-integer		fwd-status = sf-integer
	ttl = sf-integer		ttl = sf-integer
	stored = sf-boolean		stored = sf-boolean
	collapsed = sf-boolean		collapsed = sf-boolean
	key = sf-string		key = sf-string
	detail = sf-token / sf-string		detail = sf-token / sf-string
	2.1. The hit parameter		2.1. The hit parameter
	"hit", when true, indicates that the request was satisfied by the		"hit", when true, indicates that the request was satisfied by the
	cache; i.e., it did not go forward and the response was obtained from		cache; i.e., it did not go forward, and the response was obtained
	the cache. A response that originally was produced by the origin but		from the cache. A response that originally was produced by the
	was modified by the cache (for example, a 304 or 206 status code) is		origin but was modified by the cache (for example, a 304 or 206
	still considered a hit.		status code) is still considered a hit.
	"hit" and "fwd" are exclusive; only one of them should appear on each		"hit" and "fwd" are exclusive; only one of them should appear on each
	list member.		list member.
	2.2. The fwd parameter		2.2. The fwd parameter
	"fwd" indicates that the request went forward towards the origin, and		"fwd" indicates that the request went forward towards the origin, and
	why.		why.
	The following values are defined to explain why the request went		The following values are defined to explain why the request went
	skipping to change at page 5, line 14 ¶		skipping to change at page 5, line 14 ¶
	2.3. The fwd-status parameter		2.3. The fwd-status parameter
	"fwd-status" indicates what status code the next hop server returned		"fwd-status" indicates what status code the next hop server returned
	in response to the request. Only meaningful when "fwd" is present;		in response to the request. Only meaningful when "fwd" is present;
	if "fwd-status" is not present but "fwd" is, it defaults to the		if "fwd-status" is not present but "fwd" is, it defaults to the
	status code sent in the response.		status code sent in the response.
	This parameter is useful to distinguish cases when the next hop		This parameter is useful to distinguish cases when the next hop
	server sends a 304 Not Modified response to a conditional request, or		server sends a 304 Not Modified response to a conditional request, or
	a 206 Partial Response due to a range request.		a 206 Partial Response because of a range request.
	2.4. The ttl parameter		2.4. The ttl parameter
	"ttl" indicates the response's remaining freshness lifetime as		"ttl" indicates the response's remaining freshness lifetime as
	calculated by the cache, as an integer number of seconds, measured		calculated by the cache, as an integer number of seconds, measured
	when the response is sent by the cache. This includes freshness		when the response is sent by the cache. This includes freshness
	assigned by the cache; e.g., through heuristics, local configuration,		assigned by the cache; e.g., through heuristics, local configuration,
	or other factors. May be negative, to indicate staleness.		or other factors. May be negative, to indicate staleness.
	2.5. The stored parameter		2.5. The stored parameter
	skipping to change at page 7, line 41 ¶		skipping to change at page 7, line 41 ¶
	o Description: [a description of the parameter semantics and value]		o Description: [a description of the parameter semantics and value]
	o Reference: [to a specification defining this parameter]		o Reference: [to a specification defining this parameter]
	See the registry at https://iana.org/assignments/http-cache-status		See the registry at https://iana.org/assignments/http-cache-status
	[4] for details on where to send registration requests.		[4] for details on where to send registration requests.
	5. IANA Considerations		5. IANA Considerations
	Upon publication, please create the HTTP Cache-Status Parameters		Upon publication, please create the HTTP Cache-Status Parameters
	registry at https://iana.org/assignments/http-cache-statuses [5] and		registry at https://iana.org/assignments/http-cache-status [5] and
	populate it with the types defined in Section 2; see Section 4 for		populate it with the types defined in Section 2; see Section 4 for
	its associated procedures.		its associated procedures.
	6. Security Considerations		6. Security Considerations
	Information about a cache's content can be used to infer the activity		Attackers can use the information in Cache-Status to probe the
	of those using it. Generally, access to sensitive information in a		behaviour of the cache (and other components), and infer the activity
	cache is limited to those who are authorised to access that		of those using the cache. The Cache-Status header field may not
	information (using a variety of techniques), so this does not		create these risks on its own, but can assist attackers in exploiting
	represent an attack vector in the general sense.		them.
	However, if the Cache-Status header field is exposed to parties who		For example, knowing if a cache has stored a response can help an
	are not authorised to obtain the response it occurs within, it could		attacker execute a timing attack on sensitive data. Exposing the
	expose information about that data.		cache key can help an attacker understand modifications to the cache
			key, which may assist cache poisoning attacks. See [ENTANGLE] for
			details.
	For example, if an attacker were able to obtain the Cache-Status		The underlying risks can be mitigated with a variety of techniques
	header field from a response containing sensitive information and		(e.g., use of encryption and authentication; avoiding the inclusion
	access were limited to one person (or limited set of people), they		of attacker-controlled data in the cache key), depending on their
	could determine whether that information had been accessed before.		exact nature.
	This is similar to the information exposed by various timing attacks,
	but is arguably more reliable, since the cache is directly reporting
	its state.
	Mitigations include use of encryption (e.g., TLS [RFC8446])) to		To avoid assisting such attacks, the Cache-Status header field can be
	protect the response, and careful controls over access to response		omitted, only sent when the client is authorized to receive it, or
	header fields (as are present in the Web platform). When in doubt,		only send sensitive information (e.g., the key parameter) when the
	the Cache-Status header field can be omitted.		client is authorized.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.ietf-httpbis-header-structure]		[I-D.ietf-httpbis-header-structure]
	Nottingham, M. and P. Kamp, "Structured Field Values for		Nottingham, M. and P. Kamp, "Structured Field Values for
	HTTP", draft-ietf-httpbis-header-structure-19 (work in		HTTP", draft-ietf-httpbis-header-structure-19 (work in
	progress), June 2020.		progress), June 2020.
	skipping to change at page 9, line 7 ¶		skipping to change at page 9, line 7 ¶
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	7.2. Informative References		7.2. Informative References
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[ENTANGLE]
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Kettle, J., "Web Cache Entanglement: Novel Pathways to
	<https://www.rfc-editor.org/info/rfc8446>.		Poisoning", n.d., <https://i.blackhat.com/USA-
			20/Wednesday/us-20-Kettle-Web-Cache-Entanglement-Novel-
			Pathways-To-Poisoning-wp.pdf>.
	7.3. URIs		7.3. URIs
	[1] https://lists.w3.org/Archives/Public/ietf-http-wg/		[1] https://lists.w3.org/Archives/Public/ietf-http-wg/
	[2] https://httpwg.org/		[2] https://httpwg.org/
	[3] https://github.com/httpwg/http-extensions/labels/cache-header		[3] https://github.com/httpwg/http-extensions/labels/cache-header
	[4] https://iana.org/assignments/http-cache-status		[4] https://iana.org/assignments/http-cache-status
	[5] https://iana.org/assignments/http-cache-statuses		[5] https://iana.org/assignments/http-cache-status
	Author's Address		Author's Address
	Mark Nottingham		Mark Nottingham
	Fastly		Fastly
	made in		made in
	Prahran, VIC		Prahran, VIC
	Australia		Australia
	Email: mnot@mnot.net		Email: mnot@mnot.net
End of changes. 13 change blocks.
	37 lines changed or deleted		37 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/