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

David Ross <dross@microsoft.com> Thu, 19 July 2012 19:50 UTC

Return-Path: <dross@microsoft.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4299C11E8096 for <websec@ietfa.amsl.com>; Thu, 19 Jul 2012 12:50:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.467
X-Spam-Level:
X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIAFskIT47Gt for <websec@ietfa.amsl.com>; Thu, 19 Jul 2012 12:50:37 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id E444211E808F for <websec@ietf.org>; Thu, 19 Jul 2012 12:50:36 -0700 (PDT)
Received: from mail54-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Jul 2012 19:51:30 +0000
Received: from mail54-va3 (localhost [127.0.0.1]) by mail54-va3-R.bigfish.com (Postfix) with ESMTP id B277AC02F1 for <websec@ietf.org>; Thu, 19 Jul 2012 19:51:29 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-SpamScore: -41
X-BigFish: VS-41(zz9371I542M1432I1418I604T4015Izz1202hzz1033IL8275dhz2fh2a8h683h839h944hd25hf0ah107ah)
Received-SPF: pass (mail54-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dross@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ;
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.5; KIP:(null); UIP:(null); (null); H:SN2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT
Received: from mail54-va3 (localhost.localdomain [127.0.0.1]) by mail54-va3 (MessageSwitch) id 1342727488281410_15089; Thu, 19 Jul 2012 19:51:28 +0000 (UTC)
Received: from VA3EHSMHS013.bigfish.com (unknown [10.7.14.252]) by mail54-va3.bigfish.com (Postfix) with ESMTP id 37B2F60141 for <websec@ietf.org>; Thu, 19 Jul 2012 19:51:28 +0000 (UTC)
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS013.bigfish.com (10.7.99.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Jul 2012 19:51:27 +0000
Received: from va3outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.298.5; Thu, 19 Jul 2012 19:51:24 +0000
Received: from mail156-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Jul 2012 19:50:36 +0000
Received: from mail156-va3 (localhost [127.0.0.1]) by mail156-va3-R.bigfish.com (Postfix) with ESMTP id E4BFD2E01C4 for <websec@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Thu, 19 Jul 2012 19:50:35 +0000 (UTC)
Received: from mail156-va3 (localhost.localdomain [127.0.0.1]) by mail156-va3 (MessageSwitch) id 1342727433161366_2650; Thu, 19 Jul 2012 19:50:33 +0000 (UTC)
Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.237]) by mail156-va3.bigfish.com (Postfix) with ESMTP id 23FBD1800AC; Thu, 19 Jul 2012 19:50:33 +0000 (UTC)
Received: from SN2PRD0310HT003.namprd03.prod.outlook.com (157.56.234.5) by VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Jul 2012 19:50:30 +0000
Received: from SN2PRD0310MB395.namprd03.prod.outlook.com ([169.254.3.25]) by SN2PRD0310HT003.namprd03.prod.outlook.com ([10.255.112.38]) with mapi id 14.16.0175.005; Thu, 19 Jul 2012 19:50:22 +0000
From: David Ross <dross@microsoft.com>
To: "Hill, Brad" <bhill@paypal-inc.com>, =JeffH <Jeff.Hodges@KingsMountain.com>, IETF WebSec WG <websec@ietf.org>
Thread-Topic: [websec] Coordinating Frame-Options and CSP UI Safety directives
Thread-Index: AQHNYI6lkz8Gk35PQYOw0F4CVEc1fpcsMs4AgAH0c3CAAt5dAA==
Date: Thu, 19 Jul 2012 19:50:22 +0000
Message-ID: <9B5348748B708948989B17CC0AEA3DD0027A8479@SN2PRD0310MB395.namprd03.prod.outlook.com>
References: <4FFF6C0C.7010404@KingsMountain.com> <9B5348748B708948989B17CC0AEA3DD004936E@SN2PRD0310MB395.namprd03.prod.outlook.com> <370C9BEB4DD6154FA963E2F79ADC6F2E187BA8@DEN-EXDDA-S12.corp.ebay.com>
In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E187BA8@DEN-EXDDA-S12.corp.ebay.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [131.107.174.87]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OrganizationHeadersPreserved: SN2PRD0310HT003.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%PAYPAL-INC.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%KINGSMOUNTAIN.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14MLTC103.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14MLTC103.redmond.corp.microsoft.com
X-OriginatorOrg: microsoft.com
Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directives
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jul 2012 19:50:38 -0000

The full ancestor stack walk may be considered an artificial / unnecessary limitation given that users can only make trust decisions based on the UI at the top level.  (This is in a world where the top level is conservative, avoiding framing untrusted content.)

"I'm a little bit concerned that walking the full ancestors stack is going to become quite important as more sites start using constructs like seamless, sandboxed iframes to display untrusted content."
That's a great argument to go with AllAncestors by default and NoAncestors as opt-in.

Dave

-----Original Message-----
From: Hill, Brad [mailto:bhill@paypal-inc.com] 
Sent: Tuesday, July 17, 2012 4:33 PM
To: David Ross; =JeffH; IETF WebSec WG
Subject: RE: [websec] Coordinating Frame-Options and CSP UI Safety directives

Dave,

  What's the case for the "NoAncestors" behavior?  Is it just a performance optimization?  I'm a little bit concerned that walking the full ancestors stack is going to become quite important as more sites start using constructs like seamless, sandboxed iframes to display untrusted content.

Thanks,

Brad

> -----Original Message-----
> From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On 
> Behalf Of David Ross
> Sent: Monday, July 16, 2012 10:55 AM
> To: =JeffH; IETF WebSec WG
> Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety 
> directives
> 
> In the interest of bloat as measured in bits, in this case it makes 
> sense to optimize for (2), reducing header value bloat, even if this 
> is at the expense of (1), reducing header name bloat.  I was worried 
> that with CSP we can't achieve on (2).  But if we can specify the ABNF 
> as you suggest below, that solves the problem.
> 
> I also would like to see the inclusion of the AllAncestors flag as you 
> suggest below.  Or if it makes more sense here, a "NoAncestors" flag.
> 
> Dave
> 
> -----Original Message-----
> From: =JeffH [mailto:Jeff.Hodges@KingsMountain.com]
> Sent: Thursday, July 12, 2012 5:30 PM
> To: David Ross; IETF WebSec WG
> Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety 
> directives
> 
> thanks for your thoughts Dave,
> 
>  > My concern is mostly around the degree to which a move to CSP might  
> > complicate or stall the process.
> 
> by this I presume you mean the process of producing a spec for a 
> standardized "frame-options" (i.e., the successor to "x-frame-options").
> 
> I don't think leveraging CSP as a framework, per se, would necessarily 
> slow this down.
> 
>  >  I'd also prefer not to see additional use  > cases pop up (eg: 
> click fraud
> prevention) that just were never in scope  > before.
> 
> I think it's reasonable to discuss whether the "frame-options" policy 
> directive (aka "frame-ancestors", "embed-ancestors") should be 
> specified as a part of the nascent "UI Safety directives" spec (in W3C 
> WebAppSec), or the CSP 1.1 spec (in W3C WebAppSec), or as a stand-alone spec.
> 
> 
>  > I think that w.r.t. header bloat,
> 
> Ah, so there's two aspects to "header bloat" in this discussion..
> 
> 1. "header bloat" in relation to possibly defining yet another HTTP 
> header field to convey a security policy, i.e. a stand-alone 
> "frame-options" header field.
> 
> 2. "header value bloat" in terms of having a header field into which 
> server operators may feel obliged to cram a huge list of items (i.e., origins).
> 
>  From a high-level perspective, casting "frame-options" as a CSP 
> directive works towards addressing (1).
> 
> 
>  > the most sensible approach is to only allow one origin to be specified.
> 
> And this statement is addressing (2).
> 
> 
>  > CSP by-design facilitates the use of multiple origins.
> 
> However, the ABNF of any particular CSP directive can be crafted in 
> order to allow only one origin to be specified as a value, e.g. like so..
> 
>    directive-name  = "frame-options"
>    directive-value = host-source
> 
> [ where host-source is defined as..
> 
>    host-source       = [ scheme "://" ] host [ port ]
> ]
> 
>  > As we've discussed w/Frame-Options, there is a design pattern to  > 
> make the more basic single-origin approach functional.
> 
> understood.
> 
> (fwiw, I'd term what you're calling a "design pattern" as a 
> "implementation and deployment technique")
> 
> 
>  > With regard to obsolescence of X-FRAME-OPTIONS, it's easy to 
> specify exactly  > what happens in the FRAME-OPTIONS spec.  I don't 
> see that CSP inherently  > improves on that but I may be missing 
> something there.
> 
> regardless of which specification vehicle we use for the "frame-options"
> policy
> directive, we'll be able to denote (in some fashion) that it 
> supersedes the old "x-frame-options" header. (this is going to be 
> somewhat messy in any case)
> 
> 
>  > The advantage I see of bringing FRAME-OPTIONS into CSP is that it 
> makes CSP  > more comprehensive.  But I suspect there are plenty of 
> other header- related  > security features that aren't defined by CSP 
> (eg: the origin header, cookie  > security).
> 
> well, of course CSP doesn't encompass "everything" and isn't intended to.
> But we
> certainly should be carefully considering consolidating  policy 
> directive conveyance as appropriate, and the "frame-options" (aka 
> "frame-ancestors",
> "embed-ancestors") notion seems to fall reasonably within the "content 
> security policy" space -- a key aspect being that it is regarding a 
> particular resource representation (as I presently understand it).
> 
> 
>  > Finally, as Brad pointed out in the rosetta stone thread, 
> Frame-Options  > provides the flexibility to perform only a top level 
> origin check as opposed  > to a full ancestor check.  (Specified via 
> the "AllAncestors" flag.)
> 
> Well, the "AllAncestors" flag can certainly be added to a CSP-based 
> "frame-options" policy directive. e.g. by defining a new 
> "keyword-source" of 'all-ancestors'.
> 
> =JeffH
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec