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

Tobias Gondrom <tobias.gondrom@gondrom.org> Sun, 02 September 2012 11:40 UTC

Return-Path: <tobias.gondrom@gondrom.org>
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 B744621F8A40 for <websec@ietfa.amsl.com>; Sun, 2 Sep 2012 04:40:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -93.873
X-Spam-Level:
X-Spam-Status: No, score=-93.873 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trNfoizU4nme for <websec@ietfa.amsl.com>; Sun, 2 Sep 2012 04:40:37 -0700 (PDT)
Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2E82221F8A3F for <websec@ietf.org>; Sun, 2 Sep 2012 04:40:36 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=i9eDb9RRS0/79DUjulPUVunmfjHc58coE+WuUzGTUWDOq6LwFYT/XEjBzgziH2oTBde+MGL3KCyDUNWN2qADeX3uaachAvSIu069DhGxMcpX0awBzlVEDDrE1QugiXUk; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
Received: (qmail 25958 invoked from network); 2 Sep 2012 13:40:33 +0200
Received: from n2028211917.imsbiz.com (HELO ?10.65.1.240?) (202.82.119.17) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 2 Sep 2012 13:40:32 +0200
Message-ID: <504345AC.5050800@gondrom.org>
Date: Sun, 02 Sep 2012 19:40:28 +0800
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: websec@ietf.org
References: <370C9BEB4DD6154FA963E2F79ADC6F2E1799AD@DEN-EXDDA-S12.corp.ebay.com> <4FFB67EE.406@gondrom.org> <370C9BEB4DD6154FA963E2F79ADC6F2E17AE18@DEN-EXDDA-S12.corp.ebay.com> <68291699F5EA8848B0EAC2E78480571F053A3186@TK5EX14MBXC216.redmond.corp.microsoft.com> <CAJE5ia90hJ7EQDgn7Y3u2m1Lxe=fwkG65YE7YtiBNJfDtaE0rA@mail.gmail.com> <9B5348748B708948989B17CC0AEA3DD0027A848A@SN2PRD0310MB395.namprd03.prod.outlook.com> <043AA6DA-9D3F-4EC2-B5D4-E1FF2FD0F470@w3.org>
In-Reply-To: <043AA6DA-9D3F-4EC2-B5D4-E1FF2FD0F470@w3.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
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: Sun, 02 Sep 2012 11:40:37 -0000

Hello all,

thank you for your feedback and input.

<hat="individual">

NIH (not invented here) should definitely never be reason for a decision 
- in either way.
And I would also be open to assist the WebAppSec WG in writing this tiny 
bit into CSP.

I have two main reasons why I think we should keep FO separate to CSP 
and would like to hear your thoughts about it before we should make a 
decision. (Please note that in the case of this topic I will obviously 
not be acting as WG chair.)

1. Model and Semantic Reason:
Until now, I always understood the CSP model to be about "describe the 
security policy for a loaded resource and say which parts of that 
content you can execute and which references in that content you shall 
follow and execute".
While the XFO/FO model is the reverse: describing for a resource, 
defining by whom your resource may be framed/loaded from. In my view 
that was not a natural part of the CSP model. And in my understanding 
that semantic difference was also one of the reasons why it was not done 
in CSP1.0 in the first place, but at the time agreed to be done in 
websec separately.

Or as someone else from W3C WebAppSec wrote it more clearly to me about 
a year ago:
"... removing frame-ancestors from CSP altogether if a better, 
standardized Frame-Options is available to sites. In fact, it simplifies 
the model in some ways since frame-ancestors is currently the only 
directive that restricts content from the embedded site's perspective."


2. Technical Implementation:
The current FO spec allows only one "Allow-From" URI. Which means that 
for complex framing relationships, the FO header needs to be 
written/sent on the fly on a per request basis.
My question is, what happens to only one "ALLOW-FROM" if we integrate it 
into CSP?
Can we generate individual CSPs on the fly as well (including if a CSP 
header references a file), or would this then implicitely mean we have 
to allow a list of "ALLOW-FROM"?

(please note, that the initial version did allow a list for 
"Allow-From", but there were serious concerns for performance in 
implementation for large lists and privacy matters. The change to only 
one "Allow-From" is not "written in stone", still I would like to 
understand if we limit ourselves back to the "Allow-From list" 
implicitly by putting it into CSP? I had a couple of private 
conversations on this problem in the last months, but they could not 
definitively answer to that question...)


Best regards, Tobias