Re: Does no-store in request imply no-cache?

On Mon, 18 Oct 2010, Mark Nottingham wrote:

> I'm not disputing that a response to a request with 'no-store' can't be
> used to satisfy subsequent requests; the spec is pretty clear about
> that.
> 
> The question at hand is whether a request containing 'no-store', when
> received by a cache, can be served from cache, or whether it implies
> 'no-cache.' I.e., it's not whether the response can be used in a
> subsequent response; it's whether a previous response can be used to
> satisfy it.

NO IT SHOULD NOT BE USED ... to my way of thinking, the best privacy
is achieved by *no_use_of_storage* to handle the request. I'm not sure
how I'd include no-store in a client request originating from a browser.
But if the application author went to the trouble of making such a
request, then we should err on the side of privacy and preclude any use
of storage for the request or response.


> Using a cached response to satisfy a request with 'no-store' in it
> doesn't result in leakage of information, all other things being equal.

I'd argue that to not be true. NO-STORE is a privacy oriented directive
and I don't think we have the ability to discern all the small leaks
that might occur given the clever black hats that abound. The safe path is
no use of storage.

> On 18/10/2010, at 11:22 AM, David Morris wrote:
> 
> > 
> > I don't see it as orthogonal ... no-store means no-store ... my reading
> > is still that it can't be satisfied from the cache (i'm assuming that
> > the cache entry was stored as the result of a request w/o no-store).
> > 
> > If you can't cache the result, you can't use the cache to provide the
> > result. It may be that the data being protected is the association
> > between this request and the response. Or what ever. I think the
> > cache should be ignored for a no-store request and of course if the
> > no-store first appears on the response, the new response would not
> > be cached, even if it would logically invalidate existing content.
> > 
> > On Mon, 18 Oct 2010, Mark Nottingham wrote:
> > 
> >> Right, but that's largely orthogonal to the question below; whether
> >> no-store in a request implies that a previously stored response needs to
> >> be invalidated.
> >> 
> >> Cheers,
> >> 
> >> 
> >> On 18/10/2010, at 11:05 AM, David Morris wrote:
> >> 
> >>> 
> >>> I interpret NOSTORE as a stricter restriction than NOCACHE.
> >>> If it can't be stored, it can't be used in a subsequent
> >>> response.
> >>> 
> >>> If I recall the discussion from 10 years ago correctly, the
> >>> intent was to reduce the posibility that private information
> >>> could leak via even temporary storage.
> >>> 
> >>> Dave Morris
> >>> 
> >>> On Mon, 18 Oct 2010, Mark Nottingham wrote:
> >>> 
> >>>> Thoughts re: the below?
> >>>> 
> >>>> My inclination is to clarify "any response to it" so that a cache can
> >>>> use the same cached response to serve multiple requests with no-store in
> >>>> them (or not).
> >>>> 
> >>>> Cheers,
> >>>> 
> >>>> 
> >>>> Begin forwarded message:
> >>>> 
> >>>>> From: Alex Rousskov <rousskov@measurement-factory.com>
> >>>>> Date: 23 September 2010 9:47:57 AM AEST
> >>>>> To: Mark Nottingham <mnot@yahoo-inc.com>
> >>>>> Cc: Squid Developers <squid-dev@squid-cache.org>
> >>>>> Subject: Re: Does no-store in request imply no-cache?
> >>>>> 
> >>>>> On 09/22/2010 05:05 PM, Mark Nottingham wrote:
> >>>>> 
> >>>>>> Strictly, as a request directive it means "you can't store the
> >>>>>> response to this request" -- it says nothing about whether or not you
> >>>>>> can satisfy the request from a cache.
> >>>>> 
> >>>>> Hi Mark,
> >>>>> 
> >>>>>  Let's assume the above is correct and Squid satisfied the no-store 
> >>>>> request from the cache. Should Squid purge the cached response afterwards?
> >>>>> 
> >>>>> If Squid does not purge, the next regular request will get the same 
> >>>>> cached response as the no-store request got, kind of violating the "MUST 
> >>>>> NOT store any response to it" no-store requirement.
> >>>>> 
> >>>>> If Squid purges, it is kind of silly because earlier requests could have 
> >>>>> gotten the same "sensitive" information before the no-store request came 
> >>>>> and declared the already cached information "sensitive".
> >>>>> 
> >>>>> Thank you,
> >>>>> 
> >>>>> Alex.
> >>>>> 
> >>>>> 
> >>>>>> See also:
> >>>>>> http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-11#section-3.2.1
> >>>>>> 
> >>>>>> 
> >>>>>> On 23/09/2010, at 4:27 AM, Alex Rousskov wrote:
> >>>>>> 
> >>>>>>> Hello,
> >>>>>>> 
> >>>>>>>  One interpretation of RFC 2616 allows the proxy to serve hits when
> >>>>>>> the request contains "Cache-Control: no-store". Do you think such an
> >>>>>>> interpretation is valid?
> >>>>>>> 
> >>>>>>> no-store
> >>>>>>>    The purpose of the no-store directive is to prevent the
> >>>>>>>    inadvertent release or retention of sensitive information (for
> >>>>>>>    example, on backup tapes). The no-store directive applies to the
> >>>>>>>    entire message, and MAY be sent either in a response or in a
> >>>>>>>    request. If sent in a request, a cache MUST NOT store any part of
> >>>>>>>    either this request or any response to it.

Received on Monday, 18 October 2010 00:50:44 UTC