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

[Richard Barnes <[e-mail]>]

My understanding of the goal of "existing state of the art" documents like
this is to enable users of the relevant technology to understand how it
behaves.  If there is caching behavior, then users need to know about it
(in particular, web sites that might set X-Frame-Options).  This seems like
a potentially significant interop issue, so I was going to hold the DISCUSS
until someone told me whether there's an issue there or not, i.e., whether
there's any caching behavior out in the wild.

--Richard




On Mon, Aug 19, 2013 at 1:43 PM, Barry Leiba <[e-mail]>wrote:

> 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
> >
> >
>