Roman Danyliw's No Objection on draft-ietf-httpbis-cache-header-09: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-httpbis-cache-header-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache-header/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** 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?