Subject: [HASMAT] X-FRAME-OPTIONS

From: Julian Reschke <[email-masked]>
Date: Thu, 09 Sep 2010 11:49:05 +0200

Hi,

see

<http://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx> 
and <http://www.mozilla.com/en-US/firefox/3.6.9/releasenotes/>.

Is this something the WG should consider as well?

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Thu, 9 Sep 2010 07:00:04 -0700

We could.  I'd be happy to edit it.  There's isn't much (any?)
flexibility in the protocol though.

Adam

On Thu, Sep 9, 2010 at 2:49 AM, Julian Reschke <[email-masked]> wrote:
> _______________________________________________
> HASMAT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hasmat
>

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Thu, 9 Sep 2010 10:32:56 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Julian Reschke
> 

I definitely agree that there ought to be a spec for this.  What I'm a bit torn about though is where its home should be.  

Because X-Frame-Options deals exclusively with HTML processing agents and how they want to visually represent content, I think this may more properly belong to the nascent W3C Web Application Security Working Group - http://www.w3.org/2010/07/appsecwg-charter.html

My hope is that we can come up with some sort of logical grouping Or, dare I say it taxonomy, of security controls/indicators and group them into things that are core protocol related, and those that are content/display/interpretation related.  The first group could be done in the IETF, the second in the W3C.  My thinking isn't especially well-formed on this as I don't have that grouping/taxonomy laid out.

Admittedly HSTS mostly only applies to web browsers as well since they are the main target, and yet we're working on that here.  At the same time CORS and CSP are both presumably going to be done/continue at the W3C, and X-Frame-Options seems closer to them than it does to HSTS.

Perhaps a good exercise would be for us to enumerate a bunch f the policy mechanisms we've been envisioning, and then group them according to type, home, etc.  I don't know that we need a full taxonomy of them,  but I'm open to being persuaded.

- Andy

---

From: Adam Barth <[email-masked]>
Date: Thu, 9 Sep 2010 09:39:12 -0700

> Perhaps a good exercise would be for us to enumerate a bunch f the policy mechanisms we've been envisioning, and then group them according to type, home, etc.  I don't know that we need a full taxo…

Yeah, X-Frame-Options seems like a special case of CSP.

Adam

---

From: Tony Hansen <[email-masked]>
Date: Thu, 09 Sep 2010 13:11:40 -0400

Has the ship sailed with respect to naming the header "FRAME-OPTIONS" 
instead of "X-FRAME-OPTIONS"?

     Tony Hansen

---

From: Adam Barth <[email-masked]>
Date: Thu, 9 Sep 2010 10:16:56 -0700

We could add support for Frame-Options, but we would likely not remove
support for X-Frame-Options.  The name was chosen by Microsoft when
they shipped IE8.

Adam

---

From: Devdatta Akhawe <[email-masked]>
Date: Thu, 9 Sep 2010 10:52:33 -0700

> Yeah, X-Frame-Options seems like a special case of CSP.

Additionally, CSP's version has some of the flexibility that Adam was
talking about.

cheers
devdatta