On Sat, Aug 17, 2013 at 6:45 PM, Tobias Gondrom <[email protected]>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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/websec > >
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
