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

Benjamin Kaduk 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:
----------------------------------------------------------------------

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).

Received on Monday, 9 August 2021 16:48:52 UTC