The Cache-Status HTTP Response Header Field
draft-ietf-httpbis-cache-header-10

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

Thank you for the work put into this document.

Special thanks to Tommy Pauly for his shepherd's write-up, which contains a good summary of the WG consensus and the doc reviews.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and one nit.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
I am puzzled by the use of "updates it" where the "it" is rather undefined... especially as this document 'codifies' it, hence, this is the first time it is documented so no need to update it. If I am wrong, perhaps good to add a reference to the updated document ?

Also wondering about the use of 'codifies' in a standard track document, i.e., I was expected a 'specifies'. But, as a non-English speaker, the subtle differences among the English in different continents probably escape me :-)


-- Section 2 --

Out of curiosity, why do all parameters start with "sf-" ?

How is the IP address specified ? Should RFC 5952 be referenced ?

"The Cache-Status header field is only applicable to responses that have been generated by an origin server." but how can a cache know whether it connected to the 'actual origin' and not another level of CDN ? (possibly a very naive question)

-- Section 2.2 --
Should there be a "other" value to catch up any other cases ?

== NITS ==

-- Section 2 --
Just wondering about the capitalized 'List' in 'Its value is a List' when the rest of the section uses lowercase 'list'.

I made a pull request with a few editorial suggestions, at
https://github.com/httpwg/http-extensions/pull/1595

Section 2

   The Cache-Status header field is only applicable to responses that
   have been generated by an origin server.  An intermediary SHOULD NOT
   append a Cache-Status member to responses that it generates, even if
   that intermediary contains a cache, except when the generated
   response is based upon a stored response (e.g., a 304 Not Modified or
   206 Partial Content).

Is the 304/206 supposed to be an example of what the stored response was
or what the generated response is?  (Some similar text appears in §2.1
as well, though there is more context in the latter location to clarify
the intended meaning.)

   Caches determine when it is appropriate to add the Cache-Status
   header field to a response.  Some might add it to all responses,
   whereas others might only do so when specifically configured to, or
   when the request contains a header field that activates a debugging
   mode.

In light of the security considerations, we might want to put more
caveats here (e.g., on "add it to all responses").

Section 2.2

   The most specific reason that the cache is aware of SHOULD be used.
   See also [I-D.ietf-httpbis-semantics], Section 4.

I'm not entirely sure which parts of Section 4 of -semantics are
supposed to be of note in this scenario.

Section 4

   The Expert(s) should consider the following factors when evaluating
   requests:

   *  Community feedback

Where is community feedback to occur if the registration request is sent
to IANA?  (The link to https://iana.org/assignments/http-cache-status is
not currently active and thus has no preview of what the instructions to
new registrants are.)

Section 6

As the genart reviewer notes, what we describe here seems to include
giving a lot of information to potential attackers!  That said, since
this is largely codifying existing practice into a more interoperable
form, it seems better to publish than to not publish.  I do wonder if we
could give more guidance (or references) on reliable ways to determine
whether a client is authorized to receive sensitive cache-status
information.

Is rate-limiting the generation of this header field to a single
(unauthenticated/unauthorized) source likely to be of use in mitigating
attacks?  I can think of some scenarios where it does *not* help, but am
not sure if there are cases where it actually would help...

   For example, knowing if a cache has stored a response can help an
   attacker execute a timing attack on sensitive data.  Exposing the

(nit) The next sentence is a different example, and might benefit from
some additional transition text.

Also, knowing how long a cached response will be stored ("ttl") can help
an attacker in similar ways.

   cache key can help an attacker understand modifications to the cache
   key, which may assist cache poisoning attacks.  See [ENTANGLE] for
   details.

A naive reader might read this text and think that obfuscating the
"representation of the cache key" in the "key" parameter (e.g., so as to
return the same representation for cache keys that are actually
different in some subtle edge case) would be a useful countermeasure
against such attacks.  I think it would be helpful for us to make a
statement about that idea (AFAICT, it doesn't meaningfully help security
and hinders the utility of the header field, so would be
disrecommended).

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Document references draft-ietf-httpbis-semantics-16, but -17 is the latest
available revision.

Document references draft-ietf-httpbis-cache-16, but -17 is the latest
available revision.