Responding to a few of the points in Brad's original mail on this thread...
My concern is mostly around the degree to which a move to CSP might complicate or stall the process. I'd also prefer not to see additional use cases pop up (eg: click fraud prevention) that just were never in scope before. I think that w.r.t. header bloat, the most sensible approach is to only allow one origin to be specified. CSP by-design facilitates the use of multiple origins. As we've discussed w/Frame-Options, there is a design pattern to make the more basic single-origin approach functional. I would hate to see hosts serving up source lists of hundreds of origins, just because they can. I think that is exactly what will happen if we support multiple origins. With regard to obsolescence of X-FRAME-OPTIONS, it's easy to specify exactly what happens in the FRAME-OPTIONS spec. I don't see that CSP inherently improves on that but I may be missing something there. The advantage I see of bringing FRAME-OPTIONS into CSP is that it makes CSP more comprehensive. But I suspect there are plenty of other header-related security features that aren't defined by CSP (eg: the origin header, cookie security). Finally, as Brad pointed out in the rosetta stone thread, Frame-Options provides the flexibility to perform only a top level origin check as opposed to a full ancestor check. (Specified via the "AllAncestors" flag.) David Ross dr...@microsoft.com -----Original Message----- From: websec-boun...@ietf.org [mailto:websec-boun...@ietf.org] On Behalf Of Hill, Brad Sent: Monday, July 09, 2012 5:03 PM To: Tobias Gondrom; websec@ietf.org Cc: public-webapp...@w3.org Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directives Tobias, I'm happy to move the discussion primarily to websec, and I'll drop the cc: to webappsec after this email. Thanks for the historical clarification, as well. I'm not terribly concerned about which group does the work, as much as arriving at the engineering solution that works best for user agent and resource authors, some of whom have expressed preference for moving this functionality into CSP. As both a chair and an individual, I don't have a strong preference, but I think there are reasons in favor of each option and it is worth re-opening the discussion now that the WebAppSec WG has a concrete deliverable under development to address the same general class of attacks. I'll send out a summary shortly of the similarities and differences between the various options currently proposed for some additional context. -Brad Hill _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
