Re: [websec] Coordinating Frame-Options and CSP UI Safety directives

[Thomas Roessler <[e-mail]>]

I wouldn't expect major obstacles from the W3C side to having Tobias participate there.
--
Thomas Roessler, W3C  <[e-mail]>  (@roessler)







On 2012-07-19, at 21:51 +0200, David Ross wrote:

> #1 – fair point
> #2 – I was worried that the current mechanism was multi-origin only, but it sounds like that’s not the case.  If so, this is good.
>  
> NIH doesn’t sound like a great reason at all.
>  
> Question for Tobias -- with a move to push this from the IETF to the W3C/CSP, given your IETF affiliation would you still be able to contribute time to this project?  (Sorry if that’s an exceedingly blunt question, I’m not trying to step on toes here.)  Your work here thus far has been absolutely invaluable and has allowed XFO/FO to make forward progress with very little overhead.  I really don’t want to lose the momentum.
>  
> Dave
>  
>  
> From: Adam Barth [mailto:[e-mail]] 
> Sent: Wednesday, July 18, 2012 4:17 PM
> To: David Ross
> Cc: Hill, Brad; Tobias Gondrom; [e-mail]
> Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directives
>  
> Here are two reasons we should make Frame-Options into a Content-Security-Policy directive rather than yet-another-one-off-HTTP-header:
>  
> 1) By centralizing all the policy bits in one string, we gain network benefits.  For example, in the Chrome extension system, we have a field in the manifest for specifying a Content Security Policy:
>  
> http://code.google.com/chrome/extensions/contentSecurityPolicy.html
> 
> While we could add a new attribute for every different bit of policy, it's better for developers if there's just one place that contains the security policy.
>  
> 2) By moving Frame-Options into CSP, we can use the same origin-specifying machinery that already exists in CSP rather than inventing yet-another-way-of-specifying origins (e.g., in allow-from in the current Frame-Options draft).  By doing that, we make all these things work the same way rather than siloing each off depending on which browser vendor first decided this bit of policy was interesting.
>  
> As far as I can tell, the main reason for not making Frame-Options a CSP directive is that CSP was Not Invented Here.
>  
> Adam
>  
> 
> On Wed, Jul 11, 2012 at 5:22 PM, David Ross <[e-mail]> wrote:
> 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
> [e-mail]
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Hill, Brad
> Sent: Monday, July 09, 2012 5:03 PM
> To: Tobias Gondrom; [e-mail]
> Cc: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/websec
> 
> 
> _______________________________________________
> websec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/websec
>  
> _______________________________________________
> websec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/websec