Subject: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT)

From: "Sean Turner" <[email-masked]>
Date: Wed, 14 Aug 2013 09:14:44 -0700

Sean Turner has entered the following ballot position for
draft-ietf-websec-x-frame-options-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

It's interesting to note that this draft says there's a problem with
folks not checking the origins of the entire ancestor tree of names of
the framing resource - but then doesn't say that sounds like a good idea
do it.  I can see the argument that might be made that this draft is just
documenting what's done now, but shouldn't we take the opportunity to do
more and recommend something along the lines of "The entire ancestor tree
of names of the framing resource SHOULD be checked to mitigate the risk
of attacks in multiple-nested scenarios" or something like that?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'd ask about how RFC 6648 applies to this, but I bet this header was out
long before the drafts that lead to RFC 6648.

s1 (penultimate paragraph): r/script/Javascript ?

s4.1: Is Figure 1 missing or is that the registration template? ;)

s5:
r/all kinds of these attack vectors/these kind of attack vectors
r/, ...)/)

Appendix A: Is this a guarantee that x-frame-options/frame-options will
be supported henceforth until the end of time in those browsers? 
Basically, I'm not sure Appendix A is needed.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 14 Aug 2013 18:30:17 +0200

> of attacks in multiple-nested scenarios" or something like that?

It seems that that should be work for the W3C folks who are working on
the successor mechanism.  This really *is* just meaning to document
what's in use now, warts and all.

Barry

---

From: Tobias Gondrom <[email-masked]>
Date: Wed, 14 Aug 2013 17:41:37 +0100

> what's in use now, warts and all.
I agree with Barry.
(And we gave according input to WebAppSec at W3C when we handed over the
goal for CSP1.1.)

Best regards, Tobias

---

From: Yoav Nir <[email-masked]>
Date: Wed, 14 Aug 2013 16:55:11 +0000

The charter mandate was to just document. I think advise to web masters might be in scope, but advise for browser makers (for example, how to harmonize the implementations) is not.

3-4 years before Peter's first draft.

> s1 (penultimate paragraph): r/script/Javascript ?

Any script. Flash can do scripting.

> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Aug 2013 13:33:10 -0400

> The charter mandate was to just document. I think advise to web masters might be in scope, but advise for browser makers (for example, how to harmonize the implementations) is not.

The document seems to currently contain quite a bit of advice for browser makers, and certainly for plugin makers.   If the above statement is really true, that advice seems like it's out of scope.   If the above statement is not true, then the advice ought to be complete.

---

From: Tobias Gondrom <[email-masked]>
Date: Wed, 14 Aug 2013 18:41:28 +0100

> The document seems to currently contain quite a bit of advice for browser makers, and certainly for plugin makers.   If the above statement is really true, that advice seems like it's out of scope.…

Ted,

it is a balancing act: the depth of advise is proportionate to the
correlation of the different implementations.
So e.g. where implementations are in sync, the advise is more detailed.

We could add a section on the how to handle nested frames, but as we
have two diverging major browser implementations in this point, that
didn't feel very productive, especially as we have the hope that CSP1.1
will replace X-Frame-Options in the future.

Best regards, Tobias

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Aug 2013 13:52:47 -0400

On Aug 14, 2013, at 1:41 PM, Tobias Gondrom <[email-masked]> wrote:
> it is a balancing act: the depth of advise is proportionate to the correlation of the different implementations. 

Right, I get the sense that the goal really is to document, not to advise, at least with respect to browser vendors.   I just posted some comments that speak to this question—I think you are doing the right thing, but you just should be clear that you are documenting existing behavior rather than specifying behavior.  That probably means that there are some bits of text that look normative right now that ought to be reworded.

---

From: Tobias Gondrom <[email-masked]>
Date: Wed, 14 Aug 2013 18:56:37 +0100

> The charter mandate was to just document. I think advise to web masters might be in scope, but advise for browser makers (for example, how to harmonize the implementations) is not.
See also my reply to Ted's email.

> 3-4 years before Peter's first draft.
Yes the header was there long before 6648. But we refer to 6648 in the
draft.
> Any script. Flash can do scripting.
Agree with Yoav. Though the main use case is Javascript. I would suggest
to keep "script" here.

>> s4.1: Is Figure 1 missing or is that the registration template? ;)
Yes, Figure 1 is the template. I did it in form of a template to
maintain static formating and xml2rfc generates the "Figure 1" at the
bottom automatically. I guess this can be mitigated by the RFC-Editor
later.

>> r/all kinds of these attack vectors/these kind of attack vectors
No. The correction would change the meaning of the sentence.
(to be clear it does help against many of the attack vectors, just not
all...)

>> Basically, I'm not sure Appendix A is needed.
Obviously it is not a guarantee that x-frame-options shall be supported
henceforth until the end of time. In fact the opposite is true: we hope
that one day it will be replaced by CSP1.1.
However, people in the WG felt it would be good to document the current
use/implementations of X-Frame-Options in this draft (though I don't
remember whether there were any strong opinions on that bit).

---

From: "Hill, Brad" <[email-masked]>
Date: Fri, 16 Aug 2013 21:52:50 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tobias Gondrom
Sent: Wednesday, August 14, 2013 9:42 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT)

Barry
I agree with Barry. 
(And we gave according input to WebAppSec at W3C when we handed over the goal for CSP1.1.)

Best regards, Tobias

-----------------

 And the ancestor walking behavior is what we have specified in the successor at W3C.

-Brad Hill

---

From: Yoav Nir <[email-masked]>
Date: Sun, 18 Aug 2013 15:09:14 +0000

Hi Sean. The text has changed in version -10. There are still no RFC 2119 words there and no recommendations to browser vendors (as we take those to be immovable objects (the implementation, not the vendors)), but the recommendations to web developers have been changed from "should be aware" to "should make sure". Since we are documenting a given situation, which we hope will be changed by the CSP work, and since web developers cannot ignore the status quo (when *is* a good time to stop targetting IE8?), does this text change satisfy you?

OLD:
                        For example, if a resource on origin A embeds
   untrusted content from origin B, that untrusted content can embed
   another resource from origin A with an X-Frame-Options: SAMEORIGIN
   policy and that check would pass if the user agent only verifies the
   top-level browsing context.  Therefore web developers should be aware
   that embedding content from other sites can leave their web pages
   vulnerable to clickjacking even if the X-Frame-Options header is
   used.

NEW:
   a.  If the browser implementation evaluates based on the origins of	
       the framed page and the framing page:	
       Suppose a web page A (from origin 1) embeds a web page B (from	
       origin 2) in a frame or iframe which in turn embeds web page C	
       (from origin 2) using the x-frame-options header in a frame.  In	
       this case web page B needs to use X-Frame-Options as well, or	
       else a malicious page A could frame page B and with that	
       indirectly also page C.  Therefore web developers should make	
       sure that all pages from an origin that is allowed to frame a	
       given resource web page C should also use X-Frame-Options or	
       otherwise risk exposing web page C indirectly to Clickjacking	
       attacks.  And so forth recursively until the top-level browsing-	
       context (i.e. most outer frame) is reached.	
	
   b.  If the browser implementation evaluates based on the origin of	
       the framed page and the top-level browsing-context (i.e. most	
       outer frame):	
       If a resource from origin A embeds untrusted content from origin	
       B, that untrusted content can embed another resource from origin	
       A with an X-Frame-Options: SAMEORIGIN policy and that check would	
       pass if the user agent only verifies the top-level browsing	
       context.  Therefore web developers should be aware that embedding	
       content from other sites can leave their web pages vulnerable to	
       clickjacking even if the X-Frame-Options header is used.

Yoav

---

From: Sean Turner <[email-masked]>
Date: Mon, 19 Aug 2013 18:37:35 -0400

This works for me I cleared.  Thanks!

spt