[Openid-specs-ab] Form Post Response Mode example has 'Pragma: no-cache'

Brian Campbell bcampbell at pingidentity.com
Fri Feb 27 21:15:05 UTC 2015


Thanks Breno,

I see you've got "Pragma: no-cache" there, which according to both RFC 2616
<http://tools.ietf.org/html/rfc2616#section-14.32> and RFC 7234
<https://tools.ietf.org/html/rfc7234#section-5.4> isn't defined for the
response and isn't reliable for anti-caching. Having read that is what led
me to bringing this thread up in the first place. But I generally assume
that Google knows what they're doing so I have to ask - do you know why
that particular one is being used?




On Thu, Feb 26, 2015 at 7:45 PM, Breno de Medeiros <breno at google.com> wrote:

> FWIW, the cache headers returned for some Google sensitive pages are:
>
> Cache-control: no-cache, no-store
> Pragma: no-cache
>
> The answer to the questions are yes and yes (where the first 'yes' should
> mean to say 'modify the headers to a commonly agreed value that has clearer
> no-caching semantics').
>
>
> On Thu, Feb 26, 2015 at 3:51 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>
>> If you can change "sensitive" to something else, I would be fine.
>> "Sensitive" has some connotation in the field of privacy and I do not want
>> confusion there.
>>
>>
>>
>>
>>
>>
>> 2015-02-26 23:28 GMT+09:00 Brian Campbell <bcampbell at pingidentity.com>:
>>
>>> I'm fine with not wanting to use the word 'sensitive' but the text you
>>> proposed doesn't seem quite right.
>>>
>>> While the "no-store" definition does mention non-volatile storage, it
>>> also talks about volatile storage and, as I read it, pretty much says don't
>>> store any part of the response or associated request, ever. From the text,
>>> quoted again below, I don't see how "no-store" is possibly insufficient.
>>>
>>> 5.2.2.3 <https://tools.ietf.org/html/rfc7234#section-5.2.2.3>.  no-store
>>>    The "no-store" response directive indicates that a cache MUST NOT
>>>    store any part of either the immediate request or response.  This
>>>    directive applies to both private and shared caches.  "MUST NOT
>>>    store" in this context means that the cache MUST NOT intentionally
>>>    store the information in non-volatile storage, and MUST make a
>>>    best-effort attempt to remove the information from volatile storage
>>>    as promptly as possible after forwarding it.
>>>
>>>
>>> Based on the text in the spec, I'm having a hard time understanding the
>>> push back on using "no-store".
>>>
>>> From a practical perspective, however, I am not well versed in what
>>> browsers and intermediate caches actual do and don't honor well. Generally,
>>> when I want to prevent something from being cached, I throw a bunch of
>>> anti-caching directives at the response and it just works out. To your
>>> point earlier, that kind of thing isn't exactly appropriate for normative
>>> text. Note also that there's not a implementation considerations section in
>>> this doc and we're trying to make only very small changes at this point.
>>>
>>> As a compromise, of sorts, what about some text like this:
>>>
>>> "Because the Authorization Response is intended to be used only once,
>>> the Authorization Server MUST instruct the User Agent (and any
>>> intermediaries) not to store or reuse the content of the response."
>>>
>>> And then, in the non-normative example, just throw in the whole kitchen
>>> sink of cache prevention headers like:
>>>
>>> Cache-Control: no-cache, no-store, max-age=0, must-revalidate, private
>>> Expires: Thu, 01 Jan 1970 00:00:00 GMT
>>>
>>>
>>> ?
>>>
>>>
>>> On Tue, Feb 24, 2015 at 5:41 PM, Nat Sakimura <sakimura at gmail.com>
>>> wrote:
>>>
>>>> Thanks Brian.
>>>>
>>>> A friendly amendment to your proposed change:
>>>>
>>>> Rationale
>>>> -----------------
>>>> 'sensitive' is either undefined or has other connotation especially in
>>>> the privacy realm, thus it probably is better to avoid the word in this
>>>> particular case.
>>>>
>>>> Also, "no-store" in our case is insufficient as cache control because
>>>> it is just concerned with a non-volatile storage.
>>>>
>>>> Proposal
>>>> --------------
>>>> Change:
>>>> Because the Authorization Response contains sensitive information, the
>>>> Authorization Server MUST include the HTTP "Cache-Control" response header
>>>> field [RFC2616] with a value of "no-store" in the response.
>>>>
>>>> To:
>>>> Because the Authorization Response contains the information that cannot
>>>> be re-used, the Authorization Server MUST include the HTTP "Cache-Control"
>>>> response header field [RFC7234] with values "no-cache" in the response.
>>>>
>>>>
>>>> I have a slight concern about "no-cache" implementation state as
>>>> RFC7234 says that it is not obeyed in some caches.
>>>> "no-cache" is semantically equivalent to , "max-age=0,
>>>> must-revalidate". Perhaps it may be better to add that in practice, but it
>>>> seems it is inappropriate to have it in a normative text. Perhaps a note in
>>>> an implementation consideration may be good.
>>>>
>>>> Nat
>>>>
>>>>
>>>> 2015-02-25 0:15 GMT+09:00 Brian Campbell <bcampbell at pingidentity.com>:
>>>>
>>>>> And it just (re)occurred to me that RFC 2616 has been obsoleted. So
>>>>> the reference in the text that I proposed in the last message should
>>>>> probably be to RFC 7234 rather than RFC 2616.  Also the current reference
>>>>> in the Form Post Response Mode to RFC 2616 for the "User Agent" term should
>>>>> probably be updated to RFC 7230.
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Feb 24, 2015 at 8:03 AM, Brian Campbell <
>>>>> bcampbell at pingidentity.com> wrote:
>>>>>
>>>>>> I think it'd be okay to have the "no-cache" directive the example as
>>>>>> well, if folks are keen on that. But it doesn't replace "no-store". The
>>>>>> example could have both like, "Cache-Control: no-cache, no-store". I don't
>>>>>> think it's necessary as "no-store" is the stricter but I think it's okay to
>>>>>> have it there too.
>>>>>>
>>>>>> On the call yesterday
>>>>>> <http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20150223/005280.html>
>>>>>> I asked if folks thought there should also be normative text in the Form
>>>>>> Post Response Mode doc about not caching the authorization response
>>>>>> containing the auto-submitting HTML form. There's some text in §5.1
>>>>>> of RFC 6749 / OAuth 2.0
>>>>>> <http://tools.ietf.org/html/rfc6749#section-5.1>that could be
>>>>>> interpreted as obviating the need for it, which says that the
>>>>>> 'authorization server MUST include the HTTP "Cache-Control" response header
>>>>>> field [RFC2616] with a value of "no-store" in any response containing
>>>>>> tokens, credentials, or other sensitive information'.  However, that's in a
>>>>>> section about the token endpoint and so could also be interpreted as not
>>>>>> applying to the authorization response from the authorization endpoint at
>>>>>> all. Thus, I'm (sorta) proposing to add the following sentence to the end
>>>>>> of §2 of OAuth 2.0 Form Post Response Mode
>>>>>> <http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html#FormPostResponseMode>,
>>>>>> 'Because the Authorization Response contains sensitive information, the
>>>>>> Authorization Server MUST include the HTTP "Cache-Control" response header
>>>>>> field [RFC2616] with a value of "no-store" in the response.'
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Feb 23, 2015 at 4:55 PM, Brian Campbell <
>>>>>> bcampbell at pingidentity.com> wrote:
>>>>>>
>>>>>>> But that text is about directives on the cache-control _request_
>>>>>>> header.
>>>>>>>
>>>>>>> The directives in question here are on the _response_.
>>>>>>>
>>>>>>> https://tools.ietf.org/html/rfc7234#section-5.2.2 is about the
>>>>>>> response directives. With
>>>>>>> https://tools.ietf.org/html/rfc7234#section-5.2.2.3 saying this
>>>>>>> about "no-store",
>>>>>>>
>>>>>>>    The "no-store" response directive indicates that a cache MUST NOT
>>>>>>>    store any part of either the immediate request or response.  This
>>>>>>>    directive applies to both private and shared caches.  "MUST NOT
>>>>>>>    store" in this context means that the cache MUST NOT intentionally
>>>>>>>    store the information in non-volatile storage, and MUST make a
>>>>>>>    best-effort attempt to remove the information from volatile storage
>>>>>>>    as promptly as possible after forwarding it.
>>>>>>>
>>>>>>> While "no-cache" at
>>>>>>> https://tools.ietf.org/html/rfc7234#section-5.2.2.2 isn't as strong:
>>>>>>>
>>>>>>>    The "no-cache" response directive indicates that the response MUST
>>>>>>>    NOT be used to satisfy a subsequent request without successful
>>>>>>>    validation on the origin server.  This allows an origin server to
>>>>>>>    prevent a cache from using it to satisfy a request without contacting
>>>>>>>    it, even by caches that have been configured to send stale responses.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Feb 23, 2015 at 4:39 PM, Mike Jones <
>>>>>>> Michael.Jones at microsoft.com> wrote:
>>>>>>>
>>>>>>>>  Brian, “Cache-control: no-store” does not seem to imply
>>>>>>>> “Cache-control: no-cache”.  I say that because of this sentence in 5.2.1.5
>>>>>>>> of https://tools.ietf.org/html/rfc7234#section-5.2.1:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>    Note that if a request containing this directive is satisfied
>>>>>>>> from a
>>>>>>>>
>>>>>>>>    cache, the no-store request directive does not apply to the
>>>>>>>> already
>>>>>>>>
>>>>>>>>    stored response.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Therefore, to be safe, I believe that we have to replace the
>>>>>>>> “Pragma: no-cache” in our example with “Cache-control: no-cache”.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Do people agree with that conclusion?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                                                             -- Mike
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *From:* John Bradley [mailto:ve7jtb at ve7jtb.com]
>>>>>>>> *Sent:* Thursday, February 19, 2015 7:19 PM
>>>>>>>> *To:* Mike Jones
>>>>>>>> *Cc:* Brian Campbell; <openid-specs-ab at lists.openid.net>
>>>>>>>> *Subject:* Re: [Openid-specs-ab] Form Post Response Mode example
>>>>>>>> has 'Pragma: no-cache'
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Yes and yes.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>  On Feb 19, 2015, at 5:08 PM, Mike Jones <
>>>>>>>> Michael.Jones at microsoft.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> First question to the working group:  Do we agree that "Pragma:
>>>>>>>> no-cache" should be changed to "Cache-Control: no-cache" in the
>>>>>>>> Form Post Response Mode spec before approval?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Second question to the working group:  If we agree to make this
>>>>>>>> change (to text that only occurs in a non-normative example), are people
>>>>>>>> comfortable doing this without restarting the 60 day review period (but
>>>>>>>> still notifying people of the change)?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> My personal answers would be “yes” and “yes” but we shouldn’t do
>>>>>>>> this at this point unless there’s working group consensus to do so.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Brian, could you also send a note to the OAuth working group
>>>>>>>> pointing this problem with RFC 6749 and RFC 6750 and asking whether errata
>>>>>>>> should be filed?  This would help get more expert eyes on the issue.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks for bringing this to our attention, Brian!
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                                                                 --
>>>>>>>> Mike
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *From:* Openid-specs-ab [
>>>>>>>> mailto:openid-specs-ab-bounces at lists.openid.net
>>>>>>>> <openid-specs-ab-bounces at lists.openid.net>] *On Behalf Of *Brian
>>>>>>>> Campbell
>>>>>>>> *Sent:* Thursday, February 19, 2015 2:17 PM
>>>>>>>> *To:* <openid-specs-ab at lists.openid.net>
>>>>>>>> *Subject:* [Openid-specs-ab] Form Post Response Mode example has
>>>>>>>> 'Pragma: no-cache'
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The example response in
>>>>>>>> http://openid.net/specs/oauth-v2-form-post-response-mode-1_0-03.html#FormPostResponseExample
>>>>>>>>  has a "Pragma: no-cache" response header.
>>>>>>>>
>>>>>>>> However both RFC 2616
>>>>>>>> <http://tools.ietf.org/html/rfc2616#section-14.32> and the shiny
>>>>>>>> new RFC 7234 <https://tools.ietf.org/html/rfc7234#section-5.4> make
>>>>>>>> special note along the lines of the following to say that it doesn't work
>>>>>>>> as response header:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>       'Note: Because the meaning of "Pragma: no-cache" in responses is
>>>>>>>>
>>>>>>>>       not specified, it does not provide a reliable replacement for
>>>>>>>>
>>>>>>>>       "Cache-Control: no-cache" in them.'
>>>>>>>>
>>>>>>>>
>>>>>>>> It doesn't really hurt anything having it in the Form Post Response
>>>>>>>> Mode document but I'm thinking it'd be better to not further perpetuate the
>>>>>>>> "Pragma: no-cache" response header myth in this specification* and that
>>>>>>>> that line should probably be removed from the example.
>>>>>>>>
>>>>>>>> Or am I wrong on this? And if so, what am I missing?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> * And, yeah, it's in Connect Core and OAuth 2.0 as well but I
>>>>>>>> figured starting with a draft that wasn't yet final was good.
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Openid-specs-ab mailing list
>>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Nat Sakimura (=nat)
>>>> Chairman, OpenID Foundation
>>>> http://nat.sakimura.org/
>>>> @_nat_en
>>>>
>>>
>>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>
>
> --
> --Breno
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150227/23499985/attachment-0001.html>


More information about the Openid-specs-ab mailing list