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

Brad,

thank you for your email.

<hat="WG chair">

I agree that, now that WebAppSec is finally also operational, we maybe 
should revive the discussion between WebAppSec and Websec about what 
topics should be done where. Either on WG level, or initially on WG 
chair level to develop a proposal to present to the WGs to decide on. 
Please note, this coordination goes both ways: discussing which features 
should be done in WebAppSec and which should better be done in Websec.

This may also mean we revive the discussion we had on where to do 
Frame-Options.

But just to be clear about the facts of the current status, it seems I 
need to correct one of your statements in your email, which may 
otherwise be a little bit misleading:
(Fortunately, I keep all my communication emails and minutes well 
preserved in an archive to be later able to refresh my memory. ;-) )
In fact, initially, between the founded Websec WG  and the still nascent 
WebAppSec WG the communication was already clearly about how to go 
forward with Frame-Options (removing the "X-" and improvements) and 
doing that in Websec and the conclusion at that time then was to do it 
as a draft in websec and not in CSP, which evidently happened as it was 
removed from the initial CSP draft and the frame-options draft was 
created. This was not about documenting the current behaviour as you 
might suggest in your email, if I read your statement correctly.
In fact, it was only recently, a couple of months ago, that actually 
Thomas Roessler and Jeff Hodges proposed to also document the existing 
(old/current) behaviour of X-Frame-Options in addition to the worked on 
Frame-Options draft in one of our IETF WebSec WG meetings - see here: 
http://www.ietf.org/proceedings/81/minutes/websec.txt  Only as a 
consequence of that we started the X-Frame-Options draft to document the 
current behaviour, too.

However, of course any past decision to do FO in websec does not 
necessarily mean it would be the only option forward to keep FO 
(Frame-Options) in WebSec.

FYI: After the Frame-Options (and X-Frame-Options) drafts were initially 
handled as individual submissions, the WebSec WG adopted the documents 
as WG drafts:
tools.ietf.org/html/draft-ietf-websec-frame-options-00
(previously: http://tools.ietf.org/html/draft-gondrom-frame-options-02)
tools.ietf.org/html/draft-ietf-websec-x-frame-options-00
(previously: http://tools.ietf.org/html/draft-gondrom-x-frame-options-02)

If you feel Websec is not the right place for FO and that this should 
instead be integrated into CSP (and possibly moved to WebAppSec), it is 
ok to have that discussion, again. However, based on the past decisions 
and the current status, I like to invite you to lead this discussion 
about possibly moving FO from Websec to WebAppSec primarily on the 
Websec WG mailing-list, as running one discussion on two separate 
mailing-lists can be confusing at best.

Thank you,

Tobias
(co-chair of websec)



On 09/07/12 19:31, Hill, Brad wrote:
> Tobias, David and other WebSec participants,
>
>   Over at the W3C WebAppSec WG we are beginning to draft a set of new directives for Content Security Policy focused specifically on User Interface Safety - protection against clickjacking and other UI Redressing attacks.
>
>   As Adam Barth suggested on this list a few weeks ago, WebSec and WebAppSec should discuss and coordinate on whether new functionality related to UI embedding, such as ALLOW-FROM or embed-ancestors, would be best developed as CSP directives or in a new Frame-Options header.
>
>   It made sense for the IETF WebSec group to be the lightest and fastest process to specify the existing behavior of X-Frame-Options, but further refinements are more in the realm of web user agent behavior.  If sites are going to specify UI safety directives using CSP, using that mechanism rather than a new Frame-Options header can save on some header bloat, as well as making it easier to interpret scenarios where a resource wants to obsolete the X-Frame-Options when new behaviors are available. (e.g., allow embedding if CSP UI Safety directives are understood, but deny it for user agents that only understand X-Frame-Options)
>
> The current editor's draft doesn't include these options, but please take a look.
>
> http://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html
>
> A proposed additional directive for this specification is:
>
> embed-ancestors
>
> The embed-options directive indicates whether the user-agent should embed the resource using a frame, iframe, object or embed tag, or equivalent functionality in non-HTML resources. Resources can use this to avoid many UI Redressing attacks by ensuring they are not embedded into other sites. This directive replicates some of the functionality of the X-Frame-Options header. The syntax for the name and value of the directive are described by the following ABNF grammar:
>
> directive-name    = "embed-ancestors"
> directive-value   = source-list
>
> Unlike policies defined in Content Security Policy 1.0, the embed-ancestors directives is not subject to the default-src directive. If this directive is not explicitly stated in the policy its value is assumed to be "*".
>
> If 'deny' is present in the source-list, the resource cannot be displayed in an embedded context, regardless of the origin attempting to do so, and all other members of the source-list are ignored. This provides functionality equivalent to the DENY value of the X-Frame-Options header.
>
> If 'deny' is not present the source-list indicates which origins are valid ancestors for the resource. An ancestor is any resource between the protected resource and the top of the window frame tree; for example, if A embeds B which embeds C, both A and B are ancestors of C. If A embeds both B and C, B is not an ancestor of C, but A still is.
>
> The 'self' source indicates that content of the same-origin as the protected resource may embed it. This provides functionality equivalent to the SAMEORIGIN value of the X-Frame-Options header.
>
>
> Thank you - we welcome your thoughts and feedback,
>
>   Brad Hill
> Co-chair, W3C WebAppSec WG
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec

Received on Monday, 9 July 2012 23:23:53 UTC