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

[Tobias Gondrom <[e-mail]>]

On 19/08/13 15:48, Richard Barnes wrote:
>
>
>
> On Sun, Aug 18, 2013 at 1:58 AM, Barry Leiba <[e-mail]
> <mailto:[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