Original text:
network.  Therefore, cache contents need to be protected as sensitive information. <del> In particular, various attacks might be amplified by being stored in a shared cache; such "cache poisoning" attacks use the cache to distribute a malicious payload to many clients, and are especially effective when an attacker can use implementation flaws, elevated privileges, or other techniques to insert such a response into a cache.  One common attack vector for cache poisoning is to exploit </del>  differences in message parsing on proxies and in user agents; see <del> message.body.length for the relevant requirements. </del>  <del> Likewise, implementation flaws (as well as misunderstanding of cache operation) might lead to caching of sensitive information (e.g., authentication credentials) that is thought to be private, exposing it to unauthorized parties. </del>  <del> Furthermore, the very use of a cache can bring about privacy concerns.  For example, if two users share a cache, and the first one browses to a site, the second may be able to detect that the other has been to that site, because the resources from it load more quickly, thanks to the cache. </del>  Note that the Set-Cookie response header field RFC6265 does not inhibit caching; a cacheable response with a Set-Cookie header field

Reviewer comments:
For .
NAME it didn't so much introduce it as much as it just changed the nature of the example.
Well, before the term "timing attack" did not appear in the spec...
... needs a rewrite. I'm thinking of splitting up into distinct sections, e.g., Cache Poisoning Timing Attacks Caching of Sensitive Information Information Leakage ... with appropriate mitigations in each (e.g., double keying).
This also adds "Timing Attacks", right. Updated change log as well.

Revised text:
network.  Therefore, cache contents need to be protected as sensitive information.  <ins> 7.1. Various attacks might be amplified by being stored in a shared cache. Such "cache poisoning" attacks use the cache to distribute a malicious payload to many clients, and are especially effective when an attacker can use implementation flaws, elevated privileges, or other techniques to insert such a response into a cache. One common attack vector for cache poisoning is to exploit </ins> differences in message parsing on proxies and in user agents; see  <ins> message.body.length for the relevant requirements regarding HTTP/1.1. 7.2. Because one of the primary uses of a cache is to optimise performance, its use can "leak" information about what resources have been previously requested. For example, if a user visits a site and their browser caches some of its responses, and then navigates to a second site, that site can attempt to load responses that it knows exists on the first site.  If they load very quickly, it can be assumed that the user has visited that site, or even a specific page on it. Such "timing attacks" can be mitigated by adding more information to the cache key, such as the identity of the referring site (to prevent the attack described above).  This is sometimes called "double keying." </ins>  <ins> 7.3. </ins>  <ins> Implementation and deployment flaws (as well as misunderstanding of cache operation) might lead to caching of sensitive information (e.g., authentication credentials) that is thought to be private, exposing it to unauthorized parties. </ins> Note that the Set-Cookie response header field RFC6265 does not inhibit caching; a cacheable response with a Set-Cookie header field