I agree it would be good to get the ALLOW-FROM in the draft consistent with [2]. The major difference does seem to be the fact that the RFC supports a list of origins for ALLOW-FROM, whereas [2] does not.
> Also, the header name is declared as "Frame-Options" rather than what's > presently implemented and deployed: "X-FRAME-OPTIONS". Since the RFC will standardize it, I think it may be appropriate to drop the X- prefix. But then also we should probably have the RFC draft explicitly specify the behavior if there are multiple conflicting X-FRAME-OPTIONS / FRAME-OPTIONS headers present in a given HTTP response. (Eg: What happens if there is both an X-FRAME-OPTIONS and a FRAME-OPTIONS header, each with ALLOW-FROM directives pointing to different sites?) David Ross [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of =JeffH Sent: Thursday, July 07, 2011 9:39 PM To: Tobias Gondrom Cc: IETF WebSec WG Subject: [websec] specify existing X-Frame-Options ? (was: Re: FYI: New draft draft-gondrom-frame-options-01) Hi Tobias -- thanks for working on this spec, it will be good to get this all more formally documented. It appears that the -01 rev of draft-gondrom-frame-options takes into account the apparently present X-Frame-Options documentation here.. [2] Combating ClickJacking With X-Frame-Options EricLaw [MSFT] 30 Mar 2010 2:42 PM <http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx> ..which apparently supersedes the prior nominal documentation.. [1] IE8 Security Part VII: ClickJacking Defenses ieblog 27 Jan 2009 9:40 PM <http://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx> ..and which draft-gondrom-frame-options-00 appears to have been based on. As Dave Ross earlier today noted in.. Re: [websec] FYI: New draft draft-gondrom-frame-options-01 http://www.ietf.org/mail-archive/web/websec/current/msg00388.html ..the -01 spec rev differs from [2] in that it allows for declaring an origin list as a value for the ALLOW-FROM directive. Also, the header name is declared as "Frame-Options" rather than what's presently implemented and deployed: "X-FRAME-OPTIONS". Why don't we (WebSec) first simply document present X-FRAME-OPTIONS practice and get that more formally nailed down before we begin enhancing/altering it ? After all, it's apparently implemented in most all major browsers, and (I hear) emitted by a fair number of web applications. Plus, there's always the question of how closely all those implementations today conform to the present de jure specification, especially the "new" ALLOW-FROM directive in [2]. This would be in the same spirit as the RFC6265 "HTTP State Management" (aka Cookies) effort where we (hopefully unambiguously) documented the present implemented and deployed cookie subprotocol. thanks, =JeffH _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
