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

[Tobias Gondrom <[e-mail]>]

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.

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


>
> (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).

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