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
- [websec] Coordinating Frame-Options and CSP UI Sa… Hill, Brad
- Re: [websec] Coordinating Frame-Options and CSP U… Tobias Gondrom
- Re: [websec] Coordinating Frame-Options and CSP U… Tobias Gondrom
- Re: [websec] Coordinating Frame-Options and CSP U… Hill, Brad
- Re: [websec] Coordinating Frame-Options and CSP U… David Ross
- Re: [websec] Coordinating Frame-Options and CSP U… =JeffH
- Re: [websec] Coordinating Frame-Options and CSP U… David Ross
- Re: [websec] Coordinating Frame-Options and CSP U… Hill, Brad
- Re: [websec] Coordinating Frame-Options and CSP U… Adam Barth
- Re: [websec] Coordinating Frame-Options and CSP U… David Ross
- Re: [websec] Coordinating Frame-Options and CSP U… David Ross
- Re: [websec] Coordinating Frame-Options and CSP U… Thomas Roessler
- Re: [websec] Coordinating Frame-Options and CSP U… Tobias Gondrom
- Re: [websec] Coordinating Frame-Options and CSP U… Adam Barth
- Re: [websec] Coordinating Frame-Options and CSP U… Tobias Gondrom
- Re: [websec] Coordinating Frame-Options and CSP U… Adam Barth
- Re: [websec] Coordinating Frame-Options and CSP U… David Ross
- Re: [websec] Coordinating Frame-Options and CSP U… Adam Barth