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

[Richard Barnes <[e-mail]>]

On Sat, Aug 17, 2013 at 6:45 PM, Tobias Gondrom
<[e-mail]>wrote:

> Dear Richard,
>
> thanks for the review and your discusses and comments.
> Answers inline.
> I followed all your suggestions in version-10, except for D2.
> Thanks for the review and all the best,
>
> Tobias
>
>
>
> On 15/08/13 02:41, Richard Barnes wrote:
> > Richard Barnes has entered the following ballot position for
> > draft-ietf-websec-x-frame-options-09: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > (D1) The privacy considerations make no sense to me.  To whom is data
> > being leaked?  To the browser?  To random people who send a request to a
> > URI?  Do you mean that X-Frame-Options leaks information about who the
> > site authorizes?  That's true, but also true of things like CORS.  If
> > this is the concern, you should recommend a mitigation that's basically
> > the same as what CORS does, namely varying the value of X-Frame-Options
> > based on the Referer or Origin header.
> Yes.
> Ok. I expanded the text and explanation of the privacy considerations
> section accordingly.
>
> >
> > (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 get this.  I'm actually just asking for some clarification about what
browsers do -- whether they do or don't cache X-Frame-Options settings.  It
seems like something that could cause problems for web site operators, so
it would be helpful to know.  Not looking for any normative text here.



> >
> > (D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI?  In other
> > words, what does it mean to send "X-Frame-Options: ALLOW-FROM
> > https://example.com/this/is/a/path?query#fragment"?
>
> Yes. You are right we can refine the definition to "serialized-origin"
> (as a subset of URI).
> Please note that according to RFC6454 we need to use "serialized-origin"
> here and not origin (as origin in RFC6454 refers also to a list of
> origins, which would not be acceptable here).
> I adjusted the text accordingly.
>
> Note: From an editorial standpoint we can debate whether to use lower
> case "serialized-origin" or capital "SERIALIZED-ORIGIN". RFC6454 uses
> lower case. So I used that one, but I am open for either.



It seems like the ABNF in this document should just import the ABNF from RF
6454.  So, "serialized-origin".



>
> >
> > (D3) In the ALLOW-FROM: what does "top level context" mean?  Do you
> > really mean the top level here, as opposed to the next one up?
> Yes. And unfortunately with the problems you outlined in the next
> sentence (which are also described in the security considerations
> sections of the draft.)
> Ted raised a related comment. So I guess the current text regarding
> nesting and potential problem is not sufficiently clear. So I will add
> further explanations. And I will add a reference to the security
> considerations section which already contains a paragraph about this
> problem. (i.e. the 2nd paragraph).
>
>
> > For
> > example, suppose A loads B in an iframe, and B loads C, and then C sends
> > an X-Frame-Options header with ALLOW-FROM.  Is the ALLOW-FROM origin
> > compared to B or A?  In either case, you should also note the attacks
> > that remain.  For example, if the answer is B, then B needs to use
> > X-Frame-Options as well, or else, A can maliciously frame A within B.  Or
> > if the answer is A, then C is trusting A not to load any malicious
> > intermediate frames B.
> I added text accordingly to section 5.
> (and I initiated a research query to re-confirm again that we still have
> the two inconsistent browser behaviour cases here (framing page vs.
> top-level frame, as I wrote in the draft).


Great, that should be fine.  I've gone ahead and cleared this point.




> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > (C1) In the Introduction, the phrase "secure web page" would seem to
> > imply that this mechanism only applies to pages delivered over HTTPS,
> > which I'm pretty sure isn't true.  Suggest just deleting "secure".
> Ok. removed.
>
> >
> > (C2) In Section 2.1, the sentence starting "And the algorithm" seems to
> > imply that ALLOW-FROM allows SAMEORIGIN requests as well, which I think
> > you actually mean something like:
> > """
> > And the algorithm to compare origins from [RFC6454] SHOULD be used to
> > verify that a referring page is of the same origin as the content (in the
> > case of SAMEORIGIN) or that the referring page's origin is identical with
> > the ALLOW-FROM URI (in the case of ALLOW-FROM).
> > """
> Thank you. I changed the text to your suggestion.
>
> >
> > _______________________________________________
> > websec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/websec
>
>