Subject: [websec] Frame embedding: One problem, three possible specs?

From: Thomas Roessler <[email-masked]>
Date: Thu, 7 Jul 2011 23:11:58 +0200

(Warning, this is cross-posted widely. One of the lists is the IETF websec mailing list, to which the IETF NOTE WELL applies: http://www.ietf.org/about/note-well.html)

Folks,

there appear to be at least three possible specifications addressing this space, with similar but different designs:

1. A proposed deliverable in the WebAppSec group to take up on X-Frame-Options and express those in CSP:
  http://www.w3.org/2011/07/appsecwg-charter.html

(We expect that this charter might go to the W3C AC for review as soon as next week.)

2. The "From-Origin" draft (aka "Cross-Origin Resource Embedding Exclusion") currently considered for publication as an FPWD in the Webapps WG:
  http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0088.html

This draft mentions integration into CSP as a possible path forward.

3. draft-gondrom-frame-options, an individual I-D mentioned to websec: 
  https://datatracker.ietf.org/doc/draft-gondrom-frame-options/
  http://www.ietf.org/mail-archive/web/websec/current/msg00388.html

How do we go about it?  One path forward might be to just proceed as currently planned and coordinate when webappsec starts working.

Another path forward might be to see whether we can agree now on what forum to take these things forward in (and what the coordination dance might look like).

Thoughts welcome.

Regards,
--
Thomas Roessler, W3C  <[email-masked]>  (@roessler)

---

From: Adam Barth <[email-masked]>
Date: Thu, 7 Jul 2011 15:23:45 -0700

My sense from talking with folks is that there isn't a lot of
enthusiasm for supporting this use case in CSP at the present time.
We're trying to concentrate on a core set of directives for the first
iteration.  If it helps reduce complexity, you might consider dropping
option (1) for the time being.

Adam

---

From: David Ross <[email-masked]>
Date: Thu, 7 Jul 2011 23:07:23 +0000

#3 is a narrowly scoped effort to standardize something that works pretty well today in practice (X-FRAME-OPTIONS).  A conflict with CSP would be bad, but per Adam it seems like overlap is looking less likely.  So proceeding down the current path on #3 sounds good to me.

David Ross
[email-masked]

-----Original Message-----
From: Adam Barth [mailto:[email-masked]] 
Sent: Thursday, July 07, 2011 3:24 PM
To: Thomas Roessler
Cc: Tobias Gondrom; Arthur Barstow; Brad Hill; Eric Rescorla; Alexey Melnikov; David Ross; Anne van Kesteren; Adrian Bateman; Brandon Sterne; Charles McCathieNevile; Maciej Stachowiak; Peter Saint-Andre; Michael(tm) Smith; Mark Nottingham; Jeff Hodges; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Frame embedding: One problem, three possible specs?

My sense from talking with folks is that there isn't a lot of enthusiasm for supporting this use case in CSP at the present time.
We're trying to concentrate on a core set of directives for the first iteration.  If it helps reduce complexity, you might consider dropping option (1) for the time being.

Adam

On Thu, Jul 7, 2011 at 2:11 PM, Thomas Roessler <[email-masked]> wrote:
> (Warning, this is cross-posted widely. One of the lists is the IETF 
> websec mailing list, to which the IETF NOTE WELL applies: 
> http://www.ietf.org/about/note-well.html)
>
>
> Folks,
>

---

From: "Hill, Brad" <[email-masked]>
Date: Thu, 7 Jul 2011 17:31:52 -0600

The latest draft of the WebAppSec charter includes a secure cross-domain framing mechanism as a distinct deliverable from the CSP, it's relation is only in proposing re-use of same browsing context capability grammar as CSP.  So retaining option #1 is not in conflict with dropping frame-ancestors from CSP v1.

#2 and #3 (and frame-ancestors in the current CSP draft) allow expression of similar policies: "This content can only be framed/embedded by these origins."  I think it makes sense to consolidate these going forward.

#1 in the new WebAppSec WG draft charter is different.  While there isn't a strawman yet, it seeks to allow expression of a policy like: "Anyone can frame this content, but it must allow X, Y and Z."  or maybe, "This frame is non-interactive unless X, Y and Z."  (where X, Y and Z might be: an unobstructed canvas, allowed to execute script, allowed to top-nav, top z-order, minimum display size, etc...) 

I think both approaches can co-exist and that #1 can proceed without conflict for now.  If the proposal that emerges is determined to be best transported as additional semantics for X-Frame-Options or From-Origin, the WebAppSec WG is already chartered to do the necessary coordination.

-Brad

-----Original Message-----
From: Adam Barth [mailto:[email-masked]] 
Sent: Thursday, July 07, 2011 3:24 PM
To: Thomas Roessler
Cc: Tobias Gondrom; Arthur Barstow; Hill, Brad; Eric Rescorla; Alexey Melnikov; David Ross; Anne van Kesteren; Adrian Bateman; Brandon Sterne; Charles McCathieNevile; Maciej Stachowiak; Peter Saint-Andre; Michael(tm) Smith; Mark Nottingham; Hodges, Jeff; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Frame embedding: One problem, three possible specs?

Adam

---

From: Thomas Roessler <[email-masked]>
Date: Tue, 12 Jul 2011 21:07:35 +0200

So, looking at this thread, here's what I suggest for the webappsecwg charter: We keep the deliverable in there, but make it very clear that the group should liaise particularly closely with websec "and other IETF work around framing policy" (or some such), explicitly to avoid conflicting or competing specifications.

That way, if the vision of complementary specs that Brad describes materializes, we have the necessary charter coverage, but we're very clear that other work is going on and should be respected.

If that's ok with everybody, I'll make the tweak before we send this to the membership.

---

From: Tobias Gondrom <[email-masked]>
Date: Sat, 23 Jul 2011 16:57:47 +0100

Hi all,

sorry for the late answer, a flu and some other duties kept me from 
answering so far.

I agree with Thomas, Adam and David, so please go ahead with the 
webappsecwg charter.

The current plan for #3 is to be adopted in websec (as http headers 
should be done in IETF) and proceed within a few months to RFC. (main 
idea is to progress the adopted X-Frame-Options to standard and enhance 
where necessary).

A conflict with current CSP would be bad, but as Adam said, I agree that 
it might be kept outside of CSP and progress normally in websec.

Kind regards, Tobias

On 12/07/11 20:07, Thomas Roessler wrote:
> Thomas Roessler, W3C<[email-masked]>   (@roessler)
>
>
>
>
>
>
>
>> On Thu, Jul 7, 2011 at 2:11 PM, Thomas Roessler<[email-masked]>  wrote:
>>> Thomas Roessler, W3C<[email-masked]>   (@roessler)
>>>
>>>
>>>
>>>
>>