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

Hi Ben,

Thanks for the feedback. I think I've addressed it all:
  https://github.com/httpwg/http-extensions/issues/1597

Please follow up there or here if you have lingering concerns.

Cheers,


> On 10 Aug 2021, at 2:48 am, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
> 
> 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).
> 
> 
> 
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 11 August 2021 02:33:00 UTC