Roman's COMMENT on cache-header

[mnot]

Is there further guidance that can be provided to inform the tradeoff between operational and security considerations?

(a) Section 2 says “While these parameters are OPTIONAL, caches are encouraged to provide as much information as possible.”

(b) Section 6 says

“Attackers can use the information in Cache-Status to probe the behaviour of the cache (and other components), and infer the activity of those using the cache. The Cache-Status header field may not create these risks on its own, but can assist attackers in exploiting them.

For example, knowing if a cache has stored a response can help an attacker execute a timing attack on sensitive data. Exposing the cache key can help an attacker understand modifications to the cache key, which may assist cache poisoning attacks. See [ENTANGLE] for details.”

On the one hand, the operational guidance in (a) seems to be saying share as much as you can to support debugging. However, the security considerations of (b) reminds the reader that the presence these parameters can be exploited. Is there any additional guidance that can be provided on how this tradeoff could or should be made?

[kaduk]

One brainstorming idea that occurred to me yesterday was the idea to "provide as much information as possible, to clients authorized to receive it"

[mnot]

I don't think that hits the right mark. 'authorised' implies a negotiation that adds complexity to the protocol, and isn't widely adopted (a few folks do it by turning on a 'debug mode' but that's hardly secure).

Much of this information is already widely promulgated by caches; e.g., see X-Cache etc. sent from most CDNs.