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
[email protected]
https://www.ietf.org/mailman/listinfo/websec
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
