Re: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT)

[Barry Leiba <[e-mail]>]

Richard:

1. I disagree with you, but more to the point...

2. ...do you really think this meets the DISCUSS criteria?

Barry

On Mon, Aug 19, 2013 at 11:42 AM, Richard Barnes <[e-mail]> wrote:
>
>
>
> On Mon, Aug 19, 2013 at 10:41 AM, Tobias Gondrom
> <[e-mail]> wrote:
>>
>> On 19/08/13 15:48, Richard Barnes wrote:
>>
>>
>>
>>
>> On Sun, Aug 18, 2013 at 1:58 AM, Barry Leiba <[e-mail]>
>> wrote:
>>>>
>>>> > (D2) It seems like this is a value that browsers might cache, to avoid
>>>> > unnecessary requests if the same page is framed in the future.  If
>>>> > this
>>>> > is something browsers do today, please say so.
>>>>
>>>> Actually I like to push back in this case, as I don't think we should go
>>>> into implementation specific details that have no effect on the bits on
>>>> the wire nor on the effective behavior of the browser.
>>>> The X-Frame-Options header determines the behaviour for every individual
>>>> requested page regarding framing in another web page in the browser.
>>>> Whether the browser caches this information and compares the request
>>>> with an existing cache from a request from before AND if the value is
>>>> identical proceeds as before or whether the browser evaluates the
>>>> X-Frame-Options header on each request should not be specified in this
>>>> draft.
>>>
>>>
>>>  I'll note also that this is particularly the case because this is
>>> documenting something that exists, but that isn't recommended for
>>> implementation.  If this were a PS that we were recommending for new
>>> implementations, it might make more sense to talk about how to do caching
>>> for better implementations.
>>>
>>> Barry
>>
>>
>> I understand.  Caching is just another aspect of existing implementation
>> behavior that I think should be documented.
>>
>> Of course, I may be off base here.  If nobody does it, and people think
>> it's patently obvious that you never would, then I could clear.
>>
>> --Richard
>>
>>
>> Richard,
>>
>> in short: I think, we really don't need and in fact should not discuss
>> caching of the existing implementations in this draft.
>>
>> Some info fyi:
>> caching has only very limited (or no) benefit here. Because the browser
>> has to check for every http-request of the resource whether the
>> X-Frame-Options header has been set and then act accordingly. It is also a
>> very simple check.
>>
>> And consider as a page itself might be dynamic, the header can change with
>> it, too.
>>
>> As mentioned in my answer before the only mini advantage of caching might
>> be that the browser sees the header is still the same as before (with a
>> simple TRUE/FALSE regex) and then doesn't have to evaluate the ruleset again
>> e.g. if ALLOW-FROM is set if you already did so in your previous call.
>> But nearly all of the X-Frame-Options requests are DENY or SAMEORIGIN in
>> which case the comparison of the header with the previous one would not be
>> much cheaper than to just run the regex rule for the header itself.
>>
>> And also, as outlined in section 2.3.2.3., servers may generate
>> X-Frame-Options header responses depending on the request.
>> Example case: Consider that we have only one serialized-origin in the
>> ALLOW-FROM directive. Now imagine a user has multiple pages open in his
>> browser tabs with one of web page 1 from domain A and the second of web page
>> 2 from domain B both frame the same page from domain C with the ALLOW-FROM
>> directive. In that case the page needs to reply to both requests with
>> different X-Frame-Options headers, the first pointing to origin A, the
>> second to origin B.
>> But then many implementations don't support the ALLOW-FROM directive....
>>
>> So to summarize my answer: we really don't need and in fact should not
>> discuss caching of the existing implementations.
>>
>> All the best, Tobias
>
>
> Again, I'm not looking for an analysis of the merits here, just what current
> browsers do.  It looks like Firefox doesn't cache anything [1], but I don't
> know about other browsers.  If anyone does, then this document should warn
> people.  If there are no known instances of caching, I'll just clear.
>
> In a related vein, the code below demonstrates that at least Firefox *will*
> accept a URI with ALLOW-FROM, and (correctly) do the comparison based on the
> origin of that URI.  If other browsers do this, then with regard to (D3), it
> seems this document should probably say that the header *syntax* allows a
> URI, but the *comparison* is done based on the origin of the URI (Section 4
> of RFC 6454).
>
> Thanks,
> --Richard
>
> [1]
> <http://dxr.mozilla.org/mozilla-central/source/docshell/base/nsDSURIContentListener.cpp#l361>
>