From tobias.gondrom@gondrom.org Sun Sep 2 04:40:37 2012 Return-Path: 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 ; 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 ; 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 ; 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 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> <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 11:40:37 -0000 Hello all, thank you for your feedback and input. 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 From ietf@adambarth.com Sun Sep 2 08:41:19 2012 Return-Path: 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 DA39F21F84A2 for ; Sun, 2 Sep 2012 08:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 vBkimAQrAwQQ for ; Sun, 2 Sep 2012 08:41:19 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B675B21F8452 for ; Sun, 2 Sep 2012 08:41:18 -0700 (PDT) Received: by eaai11 with SMTP id i11so1316832eaa.31 for ; Sun, 02 Sep 2012 08:41:17 -0700 (PDT) Received: by 10.14.203.70 with SMTP id e46mr18126046eeo.2.1346600477846; Sun, 02 Sep 2012 08:41:17 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by mx.google.com with ESMTPS id r45sm28981950eem.6.2012.09.02.08.41.14 (version=SSLv3 cipher=OTHER); Sun, 02 Sep 2012 08:41:15 -0700 (PDT) Received: by eekb45 with SMTP id b45so1684559eek.31 for ; Sun, 02 Sep 2012 08:41:14 -0700 (PDT) Received: by 10.14.182.134 with SMTP id o6mr17766447eem.26.1346600474436; Sun, 02 Sep 2012 08:41:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.128.73 with HTTP; Sun, 2 Sep 2012 08:40:44 -0700 (PDT) In-Reply-To: <504345AC.5050800@gondrom.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> <9B5348748B708948989B17CC0AEA3DD0027A848A@SN2PRD0310MB395.namprd03.prod.outlook.com> <043AA6DA-9D3F-4EC2-B5D4-E1FF2FD0F470@w3.org> <504345AC.5050800@gondrom.org> From: Adam Barth Date: Sun, 2 Sep 2012 08:40:44 -0700 Message-ID: To: Tobias Gondrom Content-Type: text/plain; charset=ISO-8859-1 Cc: websec@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 15:41:20 -0000 On Sun, Sep 2, 2012 at 4:40 AM, Tobias Gondrom wrote: > Hello all, > > thank you for your feedback and input. > > > > 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. Now that we're done with CSP 1.0, I think it make sense to take a more expansive view of the sorts of security policies that can be expressed in a Content-Security-Policy. My view is that a security policy expressed in CSP ought to have the following properties: 1) The policy should apply only to an individual resource representation. That means that the security policy is scoped to the individual HTTP response and doesn't have broader-reaching effects (e.g., about future HTTP responses). 2) The policy should only restrict privileges---not grant any privileges. That means that the security policy is useful for implementing "least privilege": you can use it to drop privileges you're not using (e.g., the ability to execute inline script) so that an attacker can't trick you into using this privileges to your detriment. X-Frame-Options / Frame-Options fits nicely into this rubric. > 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." Having a simplified model has been very helpful to us over the past year because it has let us finish CSP 1.0. Now we're done with CSP 1.0 and looking at what the next step should be in CSP's evolution. > 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"? Integrating with CSP imposes no technical restrictions in this regard. If you want to have only a single source, you can define the syntax as: directive-name = "frame-options" directive-value = source-expression Most other directives use source-list (which is just a list of source-expressions), but there's no reason we can't do something different here if that makes sense. In fact, the only hard technical restriction on the directive-value is that it conform to the following ABNF: directive-value = *( WSP / ) > (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...) I'm a bit surprised that you'd want to limit frame-options to having only one source-expression, but we can discuss that point regardless of whether we decide to integrate it with CSP. Adam From ynir@checkpoint.com Mon Sep 3 08:20:42 2012 Return-Path: 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 52B0A21F8690 for ; Mon, 3 Sep 2012 08:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.442 X-Spam-Level: X-Spam-Status: No, score=-10.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 lp9Vdq4xqh4O for ; Mon, 3 Sep 2012 08:20:36 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 421CB21F868A for ; Mon, 3 Sep 2012 08:20:35 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q83FKXHK013616 for ; Mon, 3 Sep 2012 18:20:33 +0300 X-CheckPoint: {5044C688-2-1B221DC2-4FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 3 Sep 2012 18:20:32 +0300 From: Yoav Nir To: IETF WebSec WG Date: Mon, 3 Sep 2012 18:20:42 +0300 Thread-Topic: Session in Atlanta Thread-Index: Ac2J56gbSnZkmO0iS5u33FeeUESE7g== Message-ID: <311BB24D-E6B2-4BD3-BF2E-A8757DA97365@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11575493574a772393c4af1720560960c6b34009d3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [websec] Session in Atlanta X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 15:20:44 -0000 Hi The Atlanta IETF meeting is coming up, and it's time to plan our session, i= f any. If anyone would like to make some presentation in Atlanta, please let Alexe= y, Tobias and me know by the end of this week. It's OK if you still haven't= submitted your draft (although it will be much less OK if you don't do it = in time for the meeting!), but we need to know in advance to plan the lengt= h of the session. Thanks, Alexey, Tobias and Yoav = From tobias.gondrom@gondrom.org Mon Sep 3 09:35:15 2012 Return-Path: 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 A17B121F86B5 for ; Mon, 3 Sep 2012 09:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.618 X-Spam-Level: X-Spam-Status: No, score=-94.618 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, 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 VmzsyCiEzt6m for ; Mon, 3 Sep 2012 09:35:14 -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 0A8E121F86B4 for ; Mon, 3 Sep 2012 09:35:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=fOFppqns9mlfYj4t7uw/+2EC0vNibP1Y8SR2NzlTcZ9nY66ZHj6NKse+dOf19CZCGYvtGUPJ+VRkcY7mD7haH5PcTGCrlcBjAsq+OHgMNWJCLIgVNFx29Raq+yfmfX+I; 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 14020 invoked from network); 3 Sep 2012 18:35:11 +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); 3 Sep 2012 18:35:10 +0200 Message-ID: <5044DC3B.7090202@gondrom.org> Date: Tue, 04 Sep 2012 00:35:07 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: ietf@adambarth.com 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> <9B5348748B708948989B17CC0AEA3DD0027A848A@SN2PRD0310MB395.namprd03.prod.outlook.com> <043AA6DA-9D3F-4EC2-B5D4-E1FF2FD0F470@w3.org> <504345AC.5050800@gondrom.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: websec@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 16:35:15 -0000 On 02/09/12 23:40, Adam Barth wrote: > On Sun, Sep 2, 2012 at 4:40 AM, Tobias Gondrom > wrote: >> Hello all, >> >> thank you for your feedback and input. >> >> >> >> 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. > Now that we're done with CSP 1.0, I think it make sense to take a more > expansive view of the sorts of security policies that can be expressed > in a Content-Security-Policy. My view is that a security policy > expressed in CSP ought to have the following properties: > > 1) The policy should apply only to an individual resource > representation. That means that the security policy is scoped to the > individual HTTP response and doesn't have broader-reaching effects > (e.g., about future HTTP responses). > > 2) The policy should only restrict privileges---not grant any > privileges. That means that the security policy is useful for > implementing "least privilege": you can use it to drop privileges > you're not using (e.g., the ability to execute inline script) so that > an attacker can't trick you into using this privileges to your > detriment. > > X-Frame-Options / Frame-Options fits nicely into this rubric. Well. Hm. I am not sure that I would agree that extending the CSP semantic model to the superset that then includes "defining by whom your resource may be framed/loaded from" instead of the current CSP1.0 model is necessarily a good thing. Maybe one question: If we extend the semantic of a system, it is always good if such extension is not for a group size of "1" (aka only one individual directive). Therefore my question: Are there other use cases (directives planned for 2.0) that require the same type of semantic extension or would FO be unique in that regard? If so, which semantic extensions would that be? >> 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." > Having a simplified model has been very helpful to us over the past > year because it has let us finish CSP 1.0. Now we're done with CSP > 1.0 and looking at what the next step should be in CSP's evolution. > >> 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"? > Integrating with CSP imposes no technical restrictions in this regard. > If you want to have only a single source, you can define the syntax > as: > > directive-name = "frame-options" > directive-value = source-expression > > Most other directives use source-list (which is just a list of > source-expressions), but there's no reason we can't do something > different here if that makes sense. In fact, the only hard technical > restriction on the directive-value is that it conform to the following > ABNF: > > directive-value = *( WSP / ) Adam, I am sorry. I may not have been clear enough with my question. My concern is not with regard of whether we can define such a directive (in my view this is trivial). But the question is whether we can practically implement such, or whether there are implementation problems that would forbid (or seriously discourage) dynamic generation of a CSP on a per request basis? Because that would be the consequence of only one single "Allow-From" URI (instead of list). Or to put it differently: - Have there been successful and scaling implementations of CSP that have generated the CSP header on the fly for every request? - If not, what would be the pitfalls/problems if we would do so? - What are possible performance issues with that? - And last but not least, is there a caching of CSP use case? (which could break if we generate the CSP file on the fly for every single request...) If we move FO to CSP, I would like to know whether this will break (or due to implementation/scaling problems basically forbids) the current design of "Allow-From" _before_ we do so. >> (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...) > I'm a bit surprised that you'd want to limit frame-options to having > only one source-expression, but we can discuss that point regardless > of whether we decide to integrate it with CSP. Actually, this was not my idea, but from Dave, who explained to me the performance and privacy implications when going with a (potentially long) list of allowed URIs. Personally, I could still see both ("list" or "single" URI), though I can understand the very serious concerns with "list". We can discuss the FO design decision later, however, as explained above, if the choice to move FO into CSP basically pre-decides that we must then go with a "list" (for practical/implementation reasons), I would like to know and spell out this limitation rather now than later. > > Adam From ietf@adambarth.com Mon Sep 3 10:26:15 2012 Return-Path: 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 65A1321F853A for ; Mon, 3 Sep 2012 10:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.95 X-Spam-Level: X-Spam-Status: No, score=-2.95 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 9t-nek6LEImZ for ; Mon, 3 Sep 2012 10:26:14 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 39A4621F8535 for ; Mon, 3 Sep 2012 10:26:14 -0700 (PDT) Received: by ieak13 with SMTP id k13so4353848iea.31 for ; Mon, 03 Sep 2012 10:26:12 -0700 (PDT) Received: by 10.42.61.16 with SMTP id s16mr16008795ich.7.1346693172668; Mon, 03 Sep 2012 10:26:12 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by mx.google.com with ESMTPS id ho1sm1319239igc.3.2012.09.03.10.26.09 (version=SSLv3 cipher=OTHER); Mon, 03 Sep 2012 10:26:10 -0700 (PDT) Received: by ieak13 with SMTP id k13so4353804iea.31 for ; Mon, 03 Sep 2012 10:26:09 -0700 (PDT) Received: by 10.50.195.164 with SMTP id if4mr11440588igc.20.1346693169191; Mon, 03 Sep 2012 10:26:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.129.9 with HTTP; Mon, 3 Sep 2012 10:25:38 -0700 (PDT) In-Reply-To: <5044DC3B.7090202@gondrom.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> <9B5348748B708948989B17CC0AEA3DD0027A848A@SN2PRD0310MB395.namprd03.prod.outlook.com> <043AA6DA-9D3F-4EC2-B5D4-E1FF2FD0F470@w3.org> <504345AC.5050800@gondrom.org> <5044DC3B.7090202@gondrom.org> From: Adam Barth Date: Mon, 3 Sep 2012 10:25:38 -0700 Message-ID: To: Tobias Gondrom Content-Type: text/plain; charset=ISO-8859-1 Cc: websec@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 17:26:15 -0000 On Mon, Sep 3, 2012 at 9:35 AM, Tobias Gondrom wrote: > On 02/09/12 23:40, Adam Barth wrote: >> On Sun, Sep 2, 2012 at 4:40 AM, Tobias Gondrom >> wrote: >>> >>> Hello all, >>> >>> thank you for your feedback and input. >>> >>> >>> >>> 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. >> >> Now that we're done with CSP 1.0, I think it make sense to take a more >> expansive view of the sorts of security policies that can be expressed >> in a Content-Security-Policy. My view is that a security policy >> expressed in CSP ought to have the following properties: >> >> 1) The policy should apply only to an individual resource >> representation. That means that the security policy is scoped to the >> individual HTTP response and doesn't have broader-reaching effects >> (e.g., about future HTTP responses). >> >> 2) The policy should only restrict privileges---not grant any >> privileges. That means that the security policy is useful for >> implementing "least privilege": you can use it to drop privileges >> you're not using (e.g., the ability to execute inline script) so that >> an attacker can't trick you into using this privileges to your >> detriment. >> >> X-Frame-Options / Frame-Options fits nicely into this rubric. > > Well. Hm. I am not sure that I would agree that extending the CSP semantic > model to the superset that then includes "defining by whom your resource may > be framed/loaded from" instead of the current CSP1.0 model is necessarily a > good thing. Maybe one question: If we extend the semantic of a system, it is > always good if such extension is not for a group size of "1" (aka only one > individual directive). Therefore my question: Are there other use cases > (directives planned for 2.0) that require the same type of semantic > extension or would FO be unique in that regard? If so, which semantic > extensions would that be? I'm not sure I understood your question, but I'll try to answer it anyway. We're considering a number of new directives for CSP 1.1 that aren't related to loading subresources. For example, the form-action directive is about restricting form submissions: http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#form-action--experimental We've designed CSP to be extensible, as requested by . Frame-options falls well inside the scope we envision. >>> 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." >> >> Having a simplified model has been very helpful to us over the past >> year because it has let us finish CSP 1.0. Now we're done with CSP >> 1.0 and looking at what the next step should be in CSP's evolution. >> >>> 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"? >> >> Integrating with CSP imposes no technical restrictions in this regard. >> If you want to have only a single source, you can define the syntax >> as: >> >> directive-name = "frame-options" >> directive-value = source-expression >> >> Most other directives use source-list (which is just a list of >> source-expressions), but there's no reason we can't do something >> different here if that makes sense. In fact, the only hard technical >> restriction on the directive-value is that it conform to the following >> ABNF: >> >> directive-value = *( WSP / ) > > Adam, I am sorry. I may not have been clear enough with my question. > My concern is not with regard of whether we can define such a directive (in > my view this is trivial). > > But the question is whether we can practically implement such, or whether > there are implementation problems that would forbid (or seriously > discourage) dynamic generation of a CSP on a per request basis? There are none that I'm aware of. > Because that > would be the consequence of only one single "Allow-From" URI (instead of > list). > Or to put it differently: > - Have there been successful and scaling implementations of CSP that have > generated the CSP header on the fly for every request? I'm not aware of any in the public world, but I have seen (non-public) implementations that construct the script-src whitelist dynamically based on statically analyzing the HTML templates used to generate a particular page. You might imagine that this design would be attractive in a system like Google Web Toolkit , where the framework has enough insight into how the app works to build a CSP policy. > - If not, what would be the pitfalls/problems if we would do so? There's nothing magical going on. It's just as easy to generate a Frame-Options header dynamically as it is to generate a frame-options directive in a Content-Security-Policy header dynamically. > - What are possible performance issues with that? The performance considerations are the same regardless of whether you're using a Frame-Options header or a frame-options directive in a Content-Security-Policy header. The two are isomorphic. > - And last but not least, is there a caching of CSP use case? (which could > break if we generate the CSP file on the fly for every single request...) The Content-Security-Policy header is cached in exactly the same way as the Frame-Options header. There is nothing magical going on. > If we move FO to CSP, I would like to know whether this will break (or due > to implementation/scaling problems basically forbids) the current design of > "Allow-From" _before_ we do so. It will not. >>> (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...) >> >> I'm a bit surprised that you'd want to limit frame-options to having >> only one source-expression, but we can discuss that point regardless >> of whether we decide to integrate it with CSP. > > Actually, this was not my idea, but from Dave, who explained to me the > performance and privacy implications when going with a (potentially long) > list of allowed URIs. Personally, I could still see both ("list" or "single" > URI), though I can understand the very serious concerns with "list". > We can discuss the FO design decision later, however, as explained above, if > the choice to move FO into CSP basically pre-decides that we must then go > with a "list" (for practical/implementation reasons), I would like to know > and spell out this limitation rather now than later. Moving to CSP does not imply an pre-decision on this topic. Adam From dross@microsoft.com Mon Sep 3 22:06:53 2012 Return-Path: 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 2F4B921F8540 for ; Mon, 3 Sep 2012 22:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.133 X-Spam-Level: ** X-Spam-Status: No, score=2.133 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] 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 aciXX2s5r+BJ for ; Mon, 3 Sep 2012 22:06:51 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 535B921F848B for ; Mon, 3 Sep 2012 22:06:48 -0700 (PDT) Received: from mail92-co1-R.bigfish.com (10.243.78.236) by CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 05:06:47 +0000 Received: from mail92-co1 (localhost [127.0.0.1]) by mail92-co1-R.bigfish.com (Postfix) with ESMTP id 78D9D580093 for ; Tue, 4 Sep 2012 05:06:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -52 X-BigFish: VS-52(zzbb2dI98dI9371I542M1432Ib08R604T14ffIzz1202hzz1033IL8275bh8275dhz2fh2a8h683h839h944hd25hf0ah107ah1220h1155h) Received-SPF: pass (mail92-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dross@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.5; KIP:(null); UIP:(null); (null); H:SN2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail92-co1 (localhost.localdomain [127.0.0.1]) by mail92-co1 (MessageSwitch) id 1346735204974845_9252; Tue, 4 Sep 2012 05:06:44 +0000 (UTC) Received: from CO1EHSMHS020.bigfish.com (unknown [10.243.78.229]) by mail92-co1.bigfish.com (Postfix) with ESMTP id EA193600046 for ; Tue, 4 Sep 2012 05:06:44 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS020.bigfish.com (10.243.66.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 05:06:44 +0000 Received: from tx2outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.318.3; Tue, 4 Sep 2012 05:06:42 +0000 Received: from mail238-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 05:06:42 +0000 Received: from mail238-tx2 (localhost [127.0.0.1]) by mail238-tx2-R.bigfish.com (Postfix) with ESMTP id 26C69880207 for ; Tue, 4 Sep 2012 05:06:42 +0000 (UTC) Received: from mail238-tx2 (localhost.localdomain [127.0.0.1]) by mail238-tx2 (MessageSwitch) id 1346735200673698_29895; Tue, 4 Sep 2012 05:06:40 +0000 (UTC) Received: from TX2EHSMHS033.bigfish.com (unknown [10.9.14.254]) by mail238-tx2.bigfish.com (Postfix) with ESMTP id 9565FC20044; Tue, 4 Sep 2012 05:06:40 +0000 (UTC) Received: from SN2PRD0310HT001.namprd03.prod.outlook.com (157.56.234.5) by TX2EHSMHS033.bigfish.com (10.9.99.133) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 05:06:39 +0000 Received: from SN2PRD0310MB395.namprd03.prod.outlook.com ([169.254.3.203]) by SN2PRD0310HT001.namprd03.prod.outlook.com ([10.255.112.36]) with mapi id 14.16.0190.008; Tue, 4 Sep 2012 05:06:39 +0000 From: David Ross To: Adam Barth , Tobias Gondrom Thread-Topic: [websec] Coordinating Frame-Options and CSP UI Safety directives Thread-Index: Ac1eARMykz8Gk35PQYOw0F4CVEc1fgAKMP0AAAFdb4AAZMpUwAFePnIAACpPKLAAInNOAAikUYAAAAhkJwAANDDUgAABw6cAABdbLXA= Date: Tue, 4 Sep 2012 05:06:39 +0000 Message-ID: <9B5348748B708948989B17CC0AEA3DD002A59B4C@SN2PRD0310MB395.namprd03.prod.outlook.com> 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> <9B5348748B708948989B17CC0AEA3DD0027A848A@SN2PRD0310MB395.namprd03.prod.outlook.com> <043AA6DA-9D3F-4EC2-B5D4-E1FF2FD0F470@w3.org> <504345AC.5050800@gondrom.org> <5044DC3B.7090202@gondrom.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.102.229] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ADAMBARTH.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GONDROM.ORG$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-FOPE-CONNECTOR: Id%59$Dn%W3.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "websec@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 05:06:53 -0000 There was a bit of discussion earlier on the list w.r.t. multi-origin vs. s= ingle-origin for allow-from. I'm very much in favor of single origin. Jus= t imagine a few years from now seeing a policy or header with 1500 origins = -- if we allow that to happen, it will happen. So I'm very happy to hear we can specify the single-origin syntax as sugges= ted below. If we're going to go with CSP for FO, I'd feel most comfortable= if we can get some confirmation that this is the POR. I agree that serving dynamic policy shouldn't be technically difficult. Bu= t I do worry about this in a larger sense. It would be good to brainstorm = implications of dynamic policy. Is there any impact to platforms, design p= atterns, etc. that may have been imagined / planned during the course of CS= P's development? It just feels like a non-trivial change to the way CSP wa= s thought out. Dave -----Original Message----- From: Adam Barth [mailto:ietf@adambarth.com]=20 Sent: Monday, September 03, 2012 10:26 AM To: Tobias Gondrom Cc: websec@ietf.org; tlr@w3.org; David Ross Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directiv= es On Mon, Sep 3, 2012 at 9:35 AM, Tobias Gondrom = wrote: > On 02/09/12 23:40, Adam Barth wrote: >> On Sun, Sep 2, 2012 at 4:40 AM, Tobias Gondrom=20 >> wrote: >>> >>> Hello all, >>> >>> thank you for your feedback and input. >>> >>> >>> >>> NIH (not invented here) should definitely never be reason for a=20 >>> decision >>> - >>> in either way. >>> And I would also be open to assist the WebAppSec WG in writing this=20 >>> tiny bit into CSP. >>> >>> I have two main reasons why I think we should keep FO separate to=20 >>> CSP and would like to hear your thoughts about it before we should=20 >>> make a decision. >>> (Please note that in the case of this topic I will obviously not be=20 >>> acting as WG chair.) >>> >>> 1. Model and Semantic Reason: >>> Until now, I always understood the CSP model to be about "describe=20 >>> the security policy for a loaded resource and say which parts of=20 >>> that content you can execute and which references in that content=20 >>> you shall follow and execute". >>> While the XFO/FO model is the reverse: describing for a resource,=20 >>> defining by whom your resource may be framed/loaded from. In my view=20 >>> that was not a natural part of the CSP model. And in my=20 >>> understanding that semantic difference was also one of the reasons=20 >>> why it was not done in CSP1.0 in the first place, but at the time=20 >>> agreed to be done in websec separately. >> >> Now that we're done with CSP 1.0, I think it make sense to take a=20 >> more expansive view of the sorts of security policies that can be=20 >> expressed in a Content-Security-Policy. My view is that a security=20 >> policy expressed in CSP ought to have the following properties: >> >> 1) The policy should apply only to an individual resource=20 >> representation. That means that the security policy is scoped to the=20 >> individual HTTP response and doesn't have broader-reaching effects=20 >> (e.g., about future HTTP responses). >> >> 2) The policy should only restrict privileges---not grant any=20 >> privileges. That means that the security policy is useful for=20 >> implementing "least privilege": you can use it to drop privileges=20 >> you're not using (e.g., the ability to execute inline script) so that=20 >> an attacker can't trick you into using this privileges to your=20 >> detriment. >> >> X-Frame-Options / Frame-Options fits nicely into this rubric. > > Well. Hm. I am not sure that I would agree that extending the CSP=20 > semantic model to the superset that then includes "defining by whom=20 > your resource may be framed/loaded from" instead of the current CSP1.0=20 > model is necessarily a good thing. Maybe one question: If we extend=20 > the semantic of a system, it is always good if such extension is not=20 > for a group size of "1" (aka only one individual directive). Therefore=20 > my question: Are there other use cases (directives planned for 2.0)=20 > that require the same type of semantic extension or would FO be unique=20 > in that regard? If so, which semantic extensions would that be? I'm not sure I understood your question, but I'll try to answer it anyway. = We're considering a number of new directives for CSP 1.1 that aren't relat= ed to loading subresources. For example, the form-action directive is abou= t restricting form submissions: http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specificatio= n.dev.html#form-action--experimental We've designed CSP to be extensible, as requested by . Frame-options falls well inside the scope we envision. >>> Or as someone else from W3C WebAppSec wrote it more clearly to me=20 >>> about a year ago: >>> "... removing frame-ancestors from CSP altogether if a better,=20 >>> standardized Frame-Options is available to sites. In fact, it=20 >>> simplifies the model in some ways since frame-ancestors is currently=20 >>> the only directive that restricts content from the embedded site's=20 >>> perspective." >> >> Having a simplified model has been very helpful to us over the past=20 >> year because it has let us finish CSP 1.0. Now we're done with CSP >> 1.0 and looking at what the next step should be in CSP's evolution. >> >>> 2. Technical Implementation: >>> The current FO spec allows only one "Allow-From" URI. Which means=20 >>> that for complex framing relationships, the FO header needs to be=20 >>> written/sent on the fly on a per request basis. >>> My question is, what happens to only one "ALLOW-FROM" if we=20 >>> integrate it into CSP? >>> Can we generate individual CSPs on the fly as well (including if a=20 >>> CSP header references a file), or would this then implicitely mean=20 >>> we have to allow a list of "ALLOW-FROM"? >> >> Integrating with CSP imposes no technical restrictions in this regard. >> If you want to have only a single source, you can define the syntax >> as: >> >> directive-name =3D "frame-options" >> directive-value =3D source-expression >> >> Most other directives use source-list (which is just a list of=20 >> source-expressions), but there's no reason we can't do something=20 >> different here if that makes sense. In fact, the only hard technical=20 >> restriction on the directive-value is that it conform to the=20 >> following >> ABNF: >> >> directive-value =3D *( WSP / ) > > Adam, I am sorry. I may not have been clear enough with my question. > My concern is not with regard of whether we can define such a=20 > directive (in my view this is trivial). > > But the question is whether we can practically implement such, or=20 > whether there are implementation problems that would forbid (or=20 > seriously > discourage) dynamic generation of a CSP on a per request basis? There are none that I'm aware of. > Because that > would be the consequence of only one single "Allow-From" URI (instead=20 > of list). > Or to put it differently: > - Have there been successful and scaling implementations of CSP that=20 > have generated the CSP header on the fly for every request? I'm not aware of any in the public world, but I have seen (non-public) impl= ementations that construct the script-src whitelist dynamically based on st= atically analyzing the HTML templates used to generate a particular page. = You might imagine that this design would be attractive in a system like Goo= gle Web Toolkit , where the fra= mework has enough insight into how the app works to build a CSP policy. > - If not, what would be the pitfalls/problems if we would do so? There's nothing magical going on. It's just as easy to generate a Frame-Op= tions header dynamically as it is to generate a frame-options directive in = a Content-Security-Policy header dynamically. > - What are possible performance issues with that? The performance considerations are the same regardless of whether you're us= ing a Frame-Options header or a frame-options directive in a Content-Securi= ty-Policy header. The two are isomorphic. > - And last but not least, is there a caching of CSP use case? (which=20 > could break if we generate the CSP file on the fly for every single=20 > request...) The Content-Security-Policy header is cached in exactly the same way as the= Frame-Options header. There is nothing magical going on. > If we move FO to CSP, I would like to know whether this will break (or=20 > due to implementation/scaling problems basically forbids) the current=20 > design of "Allow-From" _before_ we do so. It will not. >>> (please note, that the initial version did allow a list for=20 >>> "Allow-From", but there were serious concerns for performance in=20 >>> implementation for large lists and privacy matters. The change to=20 >>> only one "Allow-From" is not "written in stone", still I would like=20 >>> to understand if we limit ourselves back to the "Allow-From list"=20 >>> implicitly by putting it into CSP? I had a couple of private=20 >>> conversations on this problem in the last months, but they could not=20 >>> definitively answer to that question...) >> >> I'm a bit surprised that you'd want to limit frame-options to having=20 >> only one source-expression, but we can discuss that point regardless=20 >> of whether we decide to integrate it with CSP. > > Actually, this was not my idea, but from Dave, who explained to me the=20 > performance and privacy implications when going with a (potentially=20 > long) list of allowed URIs. Personally, I could still see both ("list" or= "single" > URI), though I can understand the very serious concerns with "list". > We can discuss the FO design decision later, however, as explained=20 > above, if the choice to move FO into CSP basically pre-decides that we=20 > must then go with a "list" (for practical/implementation reasons), I=20 > would like to know and spell out this limitation rather now than later. Moving to CSP does not imply an pre-decision on this topic. Adam From ietf@adambarth.com Mon Sep 3 22:28:37 2012 Return-Path: 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 1485521F8499 for ; Mon, 3 Sep 2012 22:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 AQHtHDU6zO6l for ; Mon, 3 Sep 2012 22:28:35 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7189221F847F for ; Mon, 3 Sep 2012 22:28:35 -0700 (PDT) Received: by eaai11 with SMTP id i11so1785708eaa.31 for ; Mon, 03 Sep 2012 22:28:34 -0700 (PDT) Received: by 10.14.204.72 with SMTP id g48mr24652312eeo.45.1346736514399; Mon, 03 Sep 2012 22:28:34 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by mx.google.com with ESMTPS id k41sm42114890eep.13.2012.09.03.22.28.32 (version=SSLv3 cipher=OTHER); Mon, 03 Sep 2012 22:28:32 -0700 (PDT) Received: by eaai11 with SMTP id i11so1785703eaa.31 for ; Mon, 03 Sep 2012 22:28:32 -0700 (PDT) Received: by 10.14.202.66 with SMTP id c42mr24779960eeo.35.1346736512246; Mon, 03 Sep 2012 22:28:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.128.73 with HTTP; Mon, 3 Sep 2012 22:28:02 -0700 (PDT) In-Reply-To: <9B5348748B708948989B17CC0AEA3DD002A59B4C@SN2PRD0310MB395.namprd03.prod.outlook.com> 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> <9B5348748B708948989B17CC0AEA3DD0027A848A@SN2PRD0310MB395.namprd03.prod.outlook.com> <043AA6DA-9D3F-4EC2-B5D4-E1FF2FD0F470@w3.org> <504345AC.5050800@gondrom.org> <5044DC3B.7090202@gondrom.org> <9B5348748B708948989B17CC0AEA3DD002A59B4C@SN2PRD0310MB395.namprd03.prod.outlook.com> From: Adam Barth Date: Mon, 3 Sep 2012 22:28:02 -0700 Message-ID: To: David Ross Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 05:28:37 -0000 On Mon, Sep 3, 2012 at 10:06 PM, David Ross wrote: > There was a bit of discussion earlier on the list w.r.t. multi-origin vs.= single-origin for allow-from. I'm very much in favor of single origin. J= ust imagine a few years from now seeing a policy or header with 1500 origin= s -- if we allow that to happen, it will happen. > > So I'm very happy to hear we can specify the single-origin syntax as sugg= ested below. If we're going to go with CSP for FO, I'd feel most comfortab= le if we can get some confirmation that this is the POR. I certainly happy to take that as the starting point. I'd still like to have a discussion about the pros and cons, but if the pros outweigh the cons, I don't have a strong objection to having only a single origin. > I agree that serving dynamic policy shouldn't be technically difficult. = But I do worry about this in a larger sense. It would be good to brainstor= m implications of dynamic policy. Is there any impact to platforms, design= patterns, etc. that may have been imagined / planned during the course of = CSP's development? It just feels like a non-trivial change to the way CSP = was thought out. I had always sort of assumed folks would dynamically generate their CSP policy because authors policy by hand is somewhat of a pain. If you have any specific concerns, I'm happy to discuss them. Adam > -----Original Message----- > From: Adam Barth [mailto:ietf@adambarth.com] > Sent: Monday, September 03, 2012 10:26 AM > To: Tobias Gondrom > Cc: websec@ietf.org; tlr@w3.org; David Ross > Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety direct= ives > > On Mon, Sep 3, 2012 at 9:35 AM, Tobias Gondrom wrote: >> On 02/09/12 23:40, Adam Barth wrote: >>> On Sun, Sep 2, 2012 at 4:40 AM, Tobias Gondrom >>> wrote: >>>> >>>> Hello all, >>>> >>>> thank you for your feedback and input. >>>> >>>> >>>> >>>> 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. >>> >>> Now that we're done with CSP 1.0, I think it make sense to take a >>> more expansive view of the sorts of security policies that can be >>> expressed in a Content-Security-Policy. My view is that a security >>> policy expressed in CSP ought to have the following properties: >>> >>> 1) The policy should apply only to an individual resource >>> representation. That means that the security policy is scoped to the >>> individual HTTP response and doesn't have broader-reaching effects >>> (e.g., about future HTTP responses). >>> >>> 2) The policy should only restrict privileges---not grant any >>> privileges. That means that the security policy is useful for >>> implementing "least privilege": you can use it to drop privileges >>> you're not using (e.g., the ability to execute inline script) so that >>> an attacker can't trick you into using this privileges to your >>> detriment. >>> >>> X-Frame-Options / Frame-Options fits nicely into this rubric. >> >> Well. Hm. I am not sure that I would agree that extending the CSP >> semantic model to the superset that then includes "defining by whom >> your resource may be framed/loaded from" instead of the current CSP1.0 >> model is necessarily a good thing. Maybe one question: If we extend >> the semantic of a system, it is always good if such extension is not >> for a group size of "1" (aka only one individual directive). Therefore >> my question: Are there other use cases (directives planned for 2.0) >> that require the same type of semantic extension or would FO be unique >> in that regard? If so, which semantic extensions would that be? > > I'm not sure I understood your question, but I'll try to answer it anyway= . We're considering a number of new directives for CSP 1.1 that aren't rel= ated to loading subresources. For example, the form-action directive is ab= out restricting form submissions: > > http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specificat= ion.dev.html#form-action--experimental > > We've designed CSP to be extensible, as requested by . > Frame-options falls well inside the scope we envision. > >>>> 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." >>> >>> Having a simplified model has been very helpful to us over the past >>> year because it has let us finish CSP 1.0. Now we're done with CSP >>> 1.0 and looking at what the next step should be in CSP's evolution. >>> >>>> 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"? >>> >>> Integrating with CSP imposes no technical restrictions in this regard. >>> If you want to have only a single source, you can define the syntax >>> as: >>> >>> directive-name =3D "frame-options" >>> directive-value =3D source-expression >>> >>> Most other directives use source-list (which is just a list of >>> source-expressions), but there's no reason we can't do something >>> different here if that makes sense. In fact, the only hard technical >>> restriction on the directive-value is that it conform to the >>> following >>> ABNF: >>> >>> directive-value =3D *( WSP / ) >> >> Adam, I am sorry. I may not have been clear enough with my question. >> My concern is not with regard of whether we can define such a >> directive (in my view this is trivial). >> >> But the question is whether we can practically implement such, or >> whether there are implementation problems that would forbid (or >> seriously >> discourage) dynamic generation of a CSP on a per request basis? > > There are none that I'm aware of. > >> Because that >> would be the consequence of only one single "Allow-From" URI (instead >> of list). >> Or to put it differently: >> - Have there been successful and scaling implementations of CSP that >> have generated the CSP header on the fly for every request? > > I'm not aware of any in the public world, but I have seen (non-public) im= plementations that construct the script-src whitelist dynamically based on = statically analyzing the HTML templates used to generate a particular page.= You might imagine that this design would be attractive in a system like G= oogle Web Toolkit , where the f= ramework has enough insight into how the app works to build a CSP policy. > >> - If not, what would be the pitfalls/problems if we would do so? > > There's nothing magical going on. It's just as easy to generate a Frame-= Options header dynamically as it is to generate a frame-options directive i= n a Content-Security-Policy header dynamically. > >> - What are possible performance issues with that? > > The performance considerations are the same regardless of whether you're = using a Frame-Options header or a frame-options directive in a Content-Secu= rity-Policy header. The two are isomorphic. > >> - And last but not least, is there a caching of CSP use case? (which >> could break if we generate the CSP file on the fly for every single >> request...) > > The Content-Security-Policy header is cached in exactly the same way as t= he Frame-Options header. There is nothing magical going on. > >> If we move FO to CSP, I would like to know whether this will break (or >> due to implementation/scaling problems basically forbids) the current >> design of "Allow-From" _before_ we do so. > > It will not. > >>>> (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...) >>> >>> I'm a bit surprised that you'd want to limit frame-options to having >>> only one source-expression, but we can discuss that point regardless >>> of whether we decide to integrate it with CSP. >> >> Actually, this was not my idea, but from Dave, who explained to me the >> performance and privacy implications when going with a (potentially >> long) list of allowed URIs. Personally, I could still see both ("list" o= r "single" >> URI), though I can understand the very serious concerns with "list". >> We can discuss the FO design decision later, however, as explained >> above, if the choice to move FO into CSP basically pre-decides that we >> must then go with a "list" (for practical/implementation reasons), I >> would like to know and spell out this limitation rather now than later. > > Moving to CSP does not imply an pre-decision on this topic. > > Adam > > > > > From bhill@paypal-inc.com Tue Sep 4 16:00:29 2012 Return-Path: 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 CA42421E8082 for ; Tue, 4 Sep 2012 16:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] 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 mgmhOFh8R4xo for ; Tue, 4 Sep 2012 16:00:29 -0700 (PDT) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDD121E805A for ; Tue, 4 Sep 2012 16:00:29 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=qlHrSVJ/4LPqaVlDjqNgLnU6D+OoeKTIBcdhS1rizOhEeEKIED/hI3sb uvUljgfdcMToKqrRiLQ2Ti0YY82/cW1Fyj7zwlvwhiLrS9COSujXgWzv6 dgJiOyHCgzMke/z; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bhill@paypal-inc.com; q=dns/txt; s=ppinc; t=1346799629; x=1378335629; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=6BjUzvE4yozwtlKIxzeeUlyagZ9YjXCWAa+F530jYR4=; b=DfYUsk+eqHumcEm1l/2SbMgno73h7jOWSqZcWWBR/LGSkcBMZrUnjUcP PS5sLsBuOQcheDvw/DI9aP0tosXPA2CqqRBHXRVEJwtCIFXM4uGXSj50T jwjsHSxGAnbs6QT; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.80,369,1344236400"; d="scan'208";a="9520817" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-EXMHT-003.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 04 Sep 2012 16:00:28 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-003.corp.ebay.com ([fe80::55d3:9d86:3fc8:dbf4%14]) with mapi id 14.02.0298.004; Tue, 4 Sep 2012 17:00:22 -0600 From: "Hill, Brad" To: "websec@ietf.org" Thread-Topic: Call for review of Content Security Policy 1.0 Thread-Index: Ac2K8Q+9qgls1oZjSieX7Gz7Krupmg== Date: Tue, 4 Sep 2012 23:00:21 +0000 Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E23634D@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: [10.245.27.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: [websec] Call for review of Content Security Policy 1.0 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 23:00:29 -0000 The Web Application Security Working Group at the W3C is planning to advanc= e Content Security Policy 1.0 to Candidate Recommendation - a final set of = features and syntax - and is seeking wide review of the document at this ti= me. We would especially value the input of members of the IETF WebSec list= . http://www.w3.org/TR/2012/WD-CSP-20120710/=20 Content Security Policy is a mechanism web applications can use to mitigate= a broad class of content injection vulnerabilities, such as cross-site scr= ipting (XSS). Content Security Policy is a declarative policy that lets the= authors (or server administrators) of a web application restrict from wher= e the application can load resources. To mitigate XSS, for example, a web application can restrict itself to load= ing scripts only from known, trusted URIs, making it difficult for an attac= ker who can inject content into the web application to inject malicious scr= ipt. Content Security Policy (CSP) is not intended as a first line of defense ag= ainst content injection vulnerabilities. Instead, CSP is best used as defen= se-in-depth, to reduce the harm caused by content injection attacks. There is often a non-trivial amount of work required to apply CSP to an exi= sting web application. To reap the greatest benefit, authors will need to m= ove all inline script and style out-of-line, for example into external scri= pts, because the user agent cannot determine whether an inline script was i= njected by an attacker. To take advantage of CSP, a web application opts into using CSP by supplyin= g a Content-Security-Policy HTTP header Such policies apply the current res= ource representation only. To supply a policy for an entire site, the serve= r needs to supply a policy with each resource representation. Please submit comments to public-webappsec@w3.org Thank you, Brad Hill Co-Chair W3C Web Application Security WG From Jeff.Hodges@KingsMountain.com Thu Sep 6 16:38:29 2012 Return-Path: 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 D0DEE21F863B for ; Thu, 6 Sep 2012 16:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=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 fYNA4urAvXr2 for ; Thu, 6 Sep 2012 16:38:29 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 3480D21F8653 for ; Thu, 6 Sep 2012 16:38:29 -0700 (PDT) Received: (qmail 10227 invoked by uid 0); 6 Sep 2012 23:38:25 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 6 Sep 2012 23:38:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=Od1iREY9KveT5A8kmqBREM5KYuVHaBe/3fd9EOLGn0M=; b=acnRWagyKcasdqrKYcFjiC+6J9o50EygFdmyJFiZnDIffR9w4j73nFdpvfDBwZYfczc0el/lHjGVrS9wCeKzQT1Ius/czDZ9ml5gAu82yjqGg8a2Rx0q5wNPRfOxth9D; Received: from [24.4.122.173] (port=57085 helo=[192.168.11.12]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1T9leT-0006hh-2F for websec@ietf.org; Thu, 06 Sep 2012 17:38:25 -0600 Message-ID: <504933EF.80602@KingsMountain.com> Date: Thu, 06 Sep 2012 16:38:23 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] handling STS header field extendability X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 23:38:29 -0000 Alexey replied: > > On 27/08/2012 21:18, Tobias Gondrom wrote: >> Hello dear websec fellows, >> >> >> we have so far only very few comments regarding this. If you feel >> strongly either way, please say so ASAP, within the next 5 days (until >> Sep-1), otherwise we will have to go with the few comments we received >> to judge consensus based on them. > > > > I don't have strong feelings either way. I don't believe we have many > (if any at all) standardized extensions anyway. yes, we don't have any imagined extensions on the table at this time. But given how we defined the ABNF, it's inherently extensible. > If people believe that there would be extensions, I don't imagine any extensions at this time (as I've said before in this thread), however.. Ben Campbell's suggestion to select an IANA registry policy now is procedurally driven -- i.e., without specifying it now, someone could down the road create an independent-submission-stream I-D that extends the STS header, creates an IANA registry with a policy of their choice, and many of us might never notice > I have a slight > preference for picking an IANA policy now. Probably IETF review. agreed. I have already have the requisite language in -12.. Additional directives extending the semantic functionality of the STS header field can be defined in other specifications, with a registry (having an IANA policy definition of FOO [RFC5226]) defined for them at such time. ..I just need to stick "IETF Review" in for FOO. ok? thanks, =JeffH From ietf@hardjono.net Tue Sep 11 07:31:47 2012 Return-Path: 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 B121621F880C for ; Tue, 11 Sep 2012 07:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.455 X-Spam-Level: * X-Spam-Status: No, score=1.455 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 xsQTE3KpH1qI for ; Tue, 11 Sep 2012 07:31:47 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id F192521F87FA for ; Tue, 11 Sep 2012 07:31:46 -0700 (PDT) Received: (qmail 2472 invoked by uid 0); 11 Sep 2012 14:31:41 -0000 Received: from unknown (HELO box602.bluehost.com) (70.40.220.102) by cpoproxy3.bluehost.com with SMTP; 11 Sep 2012 14:31:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hardjono.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=Rkj3J180err1Eu14CVZ7/lap2K77pfe7sHktwV1p9Yo=; b=cmZJ3+/6TxNMSlxHrHhQ1sy1A6ttP5SriNpxOyX/MINcXIW1s8O0/KmjsEs7Rf7PZkC5+ab/jXSWbgUMP8Zh848PNU7ib2JFl3A22noTeEF2EYyPdUW0Db7p9/1hwfq9; Received: from [18.111.36.97] (port=50953 helo=WINCE7P9IL9EJ0) by box602.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1TBRV7-0008Ff-BU; Tue, 11 Sep 2012 08:31:41 -0600 From: "Thomas Hardjono" To: Date: Tue, 11 Sep 2012 10:31:39 -0400 Message-ID: <001701cd902a$29191bf0$7b4b53d0$@hardjono.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2QKif90gB/3ky+QgyW3dZUvBfu3Q== Content-Language: en-us X-Identified-User: {3727:box602.bluehost.com:hardjono:hardjono.net} {sentby:smtp auth 18.111.36.97 authed with ietf@hardjono.net} X-Mailman-Approved-At: Wed, 12 Sep 2012 02:26:32 -0700 Subject: [websec] OASIS Webinar covering plans for SAML2.1 (25 September 2012) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 14:31:47 -0000 Folks, As some of you may know, the OASIS SSTC is currently starting work on updating the SAML2.0 specifications. OASIS will be holding a free webinar on the plans for SAML2.1. The date is Tuesday 25 September 2012 (11AM-East). Registration is below. ---------------------------------------------------------------------- ----- OASIS Webinar on SAML2.1 (25 September 2012) The 'SAML -- Right Here, Right Now' Webinar -- during this webinar, we will briefly summarize the work which has already been done and discuss plans for SAML 2.1. The next generation, SAML 2.1, will streamline and reorganize the specifications to make it easier to implement and deploy SAML in a way which is both manageable and secure. SAML 2.1 will better align the functionality of SAML which is most commonly used, while making minor enhancements and adjustments to areas such as conformance. ~ 11:00AM - Noon - New York, USA ~ 4:00PM - 5:00PM - London, United Kingdom ~ 11:00PM - Midnight - Beijing, China ~ 1:00AM - 2:00AM - Sydney, Australia (Wednesday, 26 September 2012) Register here: https://www1.gotomeeting.com/register/661177496 **Feel free to distribute to your colleagues** ---------------------------------------------------------------------- ----- __________________________________________ Thomas Hardjono MIT Kerberos Consortium email: hardjono[at]mit.edu mobile: +1 781-729-9559 __________________________________________ From internet-drafts@ietf.org Fri Sep 14 16:50:27 2012 Return-Path: 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 DADDF21F84D5; Fri, 14 Sep 2012 16:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, 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 cMN8gzrAoChW; Fri, 14 Sep 2012 16:50:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B2921F84E1; Fri, 14 Sep 2012 16:50:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120914235026.8650.69312.idtracker@ietfa.amsl.com> Date: Fri, 14 Sep 2012 16:50:26 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-strict-transport-sec-13.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 23:50:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Security Working Group of the IETF. Title : HTTP Strict Transport Security (HSTS) Author(s) : Jeff Hodges Collin Jackson Adam Barth Filename : draft-ietf-websec-strict-transport-sec-13.txt Pages : 51 Date : 2012-09-14 Abstract: This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections, and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field, and/or by other means, such as user agent configuration, for example. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport-sec There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-strict-transport-sec-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Jeff.Hodges@KingsMountain.com Fri Sep 14 16:58:09 2012 Return-Path: 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 7052221F84D5 for ; Fri, 14 Sep 2012 16:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.547 X-Spam-Level: X-Spam-Status: No, score=-101.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, 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 NlTIfZrvStQK for ; Fri, 14 Sep 2012 16:58:08 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id BA18721F84EF for ; Fri, 14 Sep 2012 16:58:08 -0700 (PDT) Received: (qmail 30938 invoked by uid 0); 14 Sep 2012 23:57:47 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy12.bluehost.com with SMTP; 14 Sep 2012 23:57:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=PN9vKFTznmmBnrOSgRWjHAuK9Os/U2j3SQ1zQ6lc7PM=; b=67aWvn4vDLfBra5JU6e+1N9kL4aA85SY0WgFRrkRZp2F8QMOrUVXo856qCKNFbgooS/nxyS7yGfQYPJDoPP9gRDzk1Nyvea/QqnIOA0ND4Vl6F+Yw65LUF759KgW2C6L; Received: from [24.4.122.173] (port=47488 helo=[192.168.11.12]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TCfla-0003cH-SI for websec@ietf.org; Fri, 14 Sep 2012 17:57:46 -0600 Message-ID: <5053C477.6010607@KingsMountain.com> Date: Fri, 14 Sep 2012 16:57:43 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: [websec] new rev: draft-ietf-websec-strict-transport-sec-13 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 23:58:09 -0000 New rev: https://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-13 please see change log excerpt included below for details. AFAIK this is ready for submission to IESG and IETF-wide Last Call. full issue ticket list for strict-transport-sec: Redline spec diff from previous rev: https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-websec-strict-transport-sec-13.txt side-by-side diff from previous rev: https://tools.ietf.org/rfcdiff?url2=draft-ietf-websec-strict-transport-sec-13.txt All issue tickets are closed. Change Log for this rev is below. =JeffH ============================================================== Appendix D. Change Log [RFCEditor: please remove this section upon publication as an RFC.] Changes are grouped by spec revision listed in reverse issuance order. D.1. For draft-ietf-websec-strict-transport-sec Changes from -12 to -13: 1. Addressed the IANA registry and IANA registry policy questions raised in Ben Campbel's Gen-ART LC review. Selected "IETF Review" for IANA policy. See the portion of this thread from this message onwards for details: 2. Clarified the questions regarding max-age=0 interacting with includeSubdomains. Expanded section 5. HSTS Mechanism Overview, Added clarification text and forward ref to S 8.1 from S 6.1.1. Added two additional examples to S 6.2 which contain max-age=0. See the thread rooted here for questions that informed this: 3. upgraded ref to draft-ietf-dane-protocol to be to RFC6698. Changes from -11 to -12: 1. Addressed various issues in Ben Campbel's Gen-ART LC review. See this message for details: Changes from -10 to -11: --- end From Jeff.Hodges@KingsMountain.com Fri Sep 14 17:16:33 2012 Return-Path: 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 30F0621F857A for ; Fri, 14 Sep 2012 17:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.643 X-Spam-Level: X-Spam-Status: No, score=-101.643 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 RUY7lGVz5fLJ for ; Fri, 14 Sep 2012 17:16:32 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id 733FD21F8570 for ; Fri, 14 Sep 2012 17:16:32 -0700 (PDT) Received: (qmail 32191 invoked by uid 0); 15 Sep 2012 00:16:09 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 15 Sep 2012 00:16:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=QHZBWn282+4fxj+txDkPgz9SQjKsT7qIDITOP99tTjw=; b=Om6BsnpRp2k+0Da9WycfSz5Q8cXhsH4tAyukTIeD3VgjAsMGtnXIUUP7sguq+C4rYnYUGXU6xKvDdq32asI6S8j6PMIfb5eY7pvavIv4noV2TqrWW+PXrp59FTGB3plZ; Received: from [24.4.122.173] (port=47594 helo=[192.168.11.12]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TCg3N-0007da-Hi; Fri, 14 Sep 2012 18:16:09 -0600 Message-ID: <5053C8C6.70808@KingsMountain.com> Date: Fri, 14 Sep 2012 17:16:06 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Brian Smith , Tobias Gondrom Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: IETF WebSec WG Subject: Re: [websec] HSTS: max-age=0 interacting with includeSubdomains X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 00:16:33 -0000 I'd replied.. > > Brian Smith added.. >> >> Tobias Gondrom wrote: >>> Actually, the proposed text does not clarify it at all in my >>> understanding. Maybe I did not make my point clear enough: the case in >>> question is: does HSTS with max-age=0 and includeSubDomains mean you >>> remove the HSTS flag (entry) for the subDomains as well (i.e. is this >>> equivalent to receiving HSTS headers with max-age=0 for all subdomains)? >>> You said "no" and that would be ok for me, but from the text you proposed >>> this would still not be clear to me. >>> >>> Do you see what I mean? >> >> I agree that the proposed change doesn't really make things less >> confusing. > > Perhaps you could suggest mods to -12 that would help clarify it from your > perspective? I re-wrote Section 5 "HSTS Mechanism Overview" to try to clarify this, in rev -13. Please take a look. thx. >> My understanding (based on this discussion) is that an HSTS header can >> only modify the HSTS information for the same host that the HSTS header >> was received on. > > correct. > >> This means that the client should not modify any information for >> sub.example.org based on information it receives from example.org, > > correct. > >> and it should not modify any information for example.org based on >> information it receives from sub.example.org. > > correct. > > >> When making a connection to a host, the client reads the entry for the >> given host, and for all parent domains that have includeSubdomains in their >> HSTS entries. > > essentially correct. Rather, the UA examines any superdomain host (aka > parent domain hosts) entries it may have and if any of them have > includeSubdomains asserted, then HSTS Policy applies to the given host; > otherwise HSTS Policy applies to the given host if it is a Known HSTS Host to > that UA. Step 5 in Section 8.3. > > >> After receiving an HSTS header from a given host, the client updates the >> entry for the given host only. > > correct. > >> When receiving an HSTS header and updating the database, the client should >> never traverse the parent/child domain hierarchy. > > correct. From barryleiba.mailing.lists@gmail.com Sat Sep 15 12:13:26 2012 Return-Path: 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 B6CE921F84F1 for ; Sat, 15 Sep 2012 12:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.958 X-Spam-Level: X-Spam-Status: No, score=-102.958 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 AAgYkuT718M4 for ; Sat, 15 Sep 2012 12:13:26 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id F17A021F84F0 for ; Sat, 15 Sep 2012 12:13:25 -0700 (PDT) Received: by lbky2 with SMTP id y2so3677080lbk.31 for ; Sat, 15 Sep 2012 12:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0jHSqkNSvSu2qA8kaQpQpBJU2S6d8N4Dfzg3wNREe7Y=; b=x98EUuHWbxQDirMqhhdHpse83lw03+6B8MkiAtmjQsokXV5TEIvVrzYimNYohaRMhO PMcWZLPnseXrAJwWljaJKn4bQ22vA19rRSXp222Ubtj95jkEjMnhHsDabwWpY5dlzDE7 iQGuPADedDiHTsGUi/mJNFN7uW2Lpmv5xW3Z3ZPg3b1g2x9TlZOTRdY2zd636Ks+R1Jo 7XVewnv0ELCC0eJqbFy4tO0MHrPCTShz0tnaDF5SpIAIMH3JA+5ZpSmPQg3Dft55dvyT Bcu3WrWo5kRI24CuZIobIZamE0K1ElIDl8oXqqKkH8VabjM2cJoE/Hjxm6myn24/Q8+T 9HTQ== MIME-Version: 1.0 Received: by 10.112.88.73 with SMTP id be9mr2432637lbb.72.1347736404167; Sat, 15 Sep 2012 12:13:24 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Sat, 15 Sep 2012 12:13:24 -0700 (PDT) In-Reply-To: <5053C477.6010607@KingsMountain.com> References: <5053C477.6010607@KingsMountain.com> Date: Sat, 15 Sep 2012 15:13:24 -0400 X-Google-Sender-Auth: W9GmjLlXxdtLnZAIhhj55G_989U Message-ID: From: Barry Leiba To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] new rev: draft-ietf-websec-strict-transport-sec-13 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 19:13:26 -0000 > please see change log excerpt included below for details. AFAIK this is > ready for submission to IESG and IETF-wide Last Call. IETF-wide last call already happened, from 11 to 25 July. The GenART review was from that. I'll be putting this on the 27 Sept IESG telechat. Barry From Jeff.Hodges@KingsMountain.com Sat Sep 15 20:52:37 2012 Return-Path: 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 EB3A621F842F for ; Sat, 15 Sep 2012 20:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.934 X-Spam-Level: X-Spam-Status: No, score=-101.934 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599, 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 NZ+HCM-Amzgy for ; Sat, 15 Sep 2012 20:52:37 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 52A8721F8422 for ; Sat, 15 Sep 2012 20:52:37 -0700 (PDT) Received: (qmail 21359 invoked by uid 0); 16 Sep 2012 03:52:13 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy12.bluehost.com with SMTP; 16 Sep 2012 03:52:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=EIeQe7SonrRAK2x6dz+Ee20ngb3sjauRLpiY5Fx0lCE=; b=iW2eTVN89MNU/O4BG2yd2pDQ7tf0gj5fGCknF6H6C31yGvGSVL6s+C+AIk7xLzIfw9N49ST27DZqXCqLh8wZvtKDAq+gysSsV3N8pDIHicztuEQDQFM/GRzoyzB1jN7G; Received: from [24.4.122.173] (port=51869 helo=[192.168.11.12]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TD5u1-0000XT-JV; Sat, 15 Sep 2012 21:52:13 -0600 Message-ID: <50554CE6.9020305@KingsMountain.com> Date: Sat, 15 Sep 2012 20:52:06 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: IETF WebSec WG Subject: Re: [websec] new rev: draft-ietf-websec-strict-transport-sec-13 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 03:52:38 -0000 >> please see change log excerpt included below for details. AFAIK this is >> ready for submission to IESG and IETF-wide Last Call. > > IETF-wide last call already happened, from 11 to 25 July. The GenART > review was from that. lol! you're of course correct. haste makes waste etc. > I'll be putting this on the 27 Sept IESG telechat. super, thanks. =JeffH From hhalpin@w3.org Mon Sep 17 10:06:06 2012 Return-Path: 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 EF45521F8723 for ; Mon, 17 Sep 2012 10:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] 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 akZvckEuhtPV for ; Mon, 17 Sep 2012 10:06:05 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 804EE21F8720 for ; Mon, 17 Sep 2012 10:06:05 -0700 (PDT) Received: from [199.254.238.242] (helo=[172.27.0.71]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1TDelo-0004ag-SZ for websec@ietf.org; Mon, 17 Sep 2012 13:06:05 -0400 Message-ID: <50575870.3080507@w3.org> Date: Mon, 17 Sep 2012 19:05:52 +0200 From: Harry Halpin User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: websec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [websec] W3C WebCrypto API (Javascript) First Public Working Draft: Request for Review X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 17:06:06 -0000 WebSec folks, The W3C has recently released the First Public Working Draft of the W3C Web Crypto API [1], a Javascript API created in a W3C Working Group with representatives of all major browsers that will expose cryptographic primitives to WebApps. As you can tell, its currently only supporting core functionality, but will likely be expanded over the course of next year. The rest of the features are going to be use-case driven and "secondary", see charter for details on possible future features for the API [2]. At this stage, we are at this stage leaving many of the issues open (14 in total, clearly listed in the spec!) but we will need to close them all as soon as possible. We'd love any comments you have, please post to public-webcrypto-comments@w3.org. Any further questions I'd be happy to answer. If there are any particular WGs whose use-cases we should make sure we handle and we should get review from, just tell me and also feel free to forward the e-mail along, cc'ing me if you think there may be questions. We are already liasoning with JOSE WG via Mike Jones. cheers, harry [1] http://www.w3.org/TR/WebCryptoAPI/ [2] http://www.w3.org/2011/11/webcryptography-charter.html#scope From tobias.gondrom@gondrom.org Mon Sep 24 04:44:34 2012 Return-Path: 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 CF0FC21F8617 for ; Mon, 24 Sep 2012 04:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.062 X-Spam-Level: X-Spam-Status: No, score=-94.062 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, 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, HTML_MESSAGE=0.001, 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 ANR0LgkUQEay for ; Mon, 24 Sep 2012 04:44:33 -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 92FA621F85C3 for ; Mon, 24 Sep 2012 04:44:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=fJS7MHxOoWYlRZ/+Dws34s6PCtGBTgbeQqZ51x9SRAMtcaosoDYLf4yjYrUKSrgZLGKiJ5k4fOUM0VysR2Fev2xIk/vJwsKON/tD1dZpWhC1anVw735DGAGtwW6euJ8T; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; Received: (qmail 9265 invoked from network); 24 Sep 2012 13:44:30 +0200 Received: from n2028211917.imsbiz.com (HELO ?10.65.1.33?) (202.82.119.17) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 24 Sep 2012 13:44:29 +0200 Message-ID: <5060479A.2010604@gondrom.org> Date: Mon, 24 Sep 2012 19:44:26 +0800 From: Tobias Gondrom 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: <5053C477.6010607@KingsMountain.com> In-Reply-To: <5053C477.6010607@KingsMountain.com> Content-Type: multipart/alternative; boundary="------------080609050206080105070307" Cc: barryleiba@computer.org Subject: Re: [websec] new rev: draft-ietf-websec-strict-transport-sec-13 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 11:44:34 -0000 This is a multi-part message in MIME format. --------------080609050206080105070307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Jeff and websec fellows, and thanks a lot for the latest version and to my understanding it indeed closes all open issues. For all fyi: Please note that the update in section 6.1 item 5. declares that future registries will be using IETF review for creation/defining. "Additional directives extending the semantic functionality of the STS header field can be defined in other specifications, with a registry (having an IANA policy definition of IETF Review [RFC5226]) defined for them at such time." There has been some discussion on this, but to my understanding no major conflicts have been raised with the proposed approach. Best regards and see you soon in Atlanta, Tobias On 15/09/12 07:57, =JeffH wrote: > New rev: > https://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-13 > > please see change log excerpt included below for details. AFAIK this > is ready for submission to IESG and IETF-wide Last Call. > > > full issue ticket list for strict-transport-sec: > > > > Redline spec diff from previous rev: > https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-websec-strict-transport-sec-13.txt > > > side-by-side diff from previous rev: > https://tools.ietf.org/rfcdiff?url2=draft-ietf-websec-strict-transport-sec-13.txt > > > > All issue tickets are closed. > > Change Log for this rev is below. > > > =JeffH > > > ============================================================== > > Appendix D. Change Log > > [RFCEditor: please remove this section upon publication as an RFC.] > > Changes are grouped by spec revision listed in reverse issuance > order. > > D.1. For draft-ietf-websec-strict-transport-sec > > Changes from -12 to -13: > > 1. Addressed the IANA registry and IANA registry policy questions > raised in Ben Campbel's Gen-ART LC review. Selected "IETF > Review" for IANA policy. See the portion of this thread from > this message onwards for details: mail-archive/web/websec/current/msg01355.html> > > 2. Clarified the questions regarding max-age=0 interacting with > includeSubdomains. Expanded section 5. HSTS Mechanism > Overview, Added clarification text and forward ref to S 8.1 > from S 6.1.1. Added two additional examples to S 6.2 which > contain max-age=0. See the thread rooted here for questions > that informed this: websec/current/msg01347.html> > > 3. upgraded ref to draft-ietf-dane-protocol to be to RFC6698. > > Changes from -11 to -12: > > 1. Addressed various issues in Ben Campbel's Gen-ART LC review. > See this message for details: mail-archive/web/websec/current/msg01324.html> > > Changes from -10 to -11: > > > > --- > end > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec --------------080609050206080105070307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello Jeff and websec fellows,

<hat="WG chair"> and <hat="document shepherd">
thanks a lot for the latest version and to my understanding it indeed closes all open issues.

For all fyi: Please note that the update in section 6.1  item 5.
declares that future registries will be using IETF review for creation/defining.

"Additional directives extending the semantic functionality of the STS
   header field can be defined in other specifications, with a registry
   (having an IANA policy definition of IETF Review [RFC5226]) defined
   for them at such time."

There has been some discussion on this, but to my understanding no major conflicts have been raised with the proposed approach.

<taking all hats off>

Best regards and see you soon in Atlanta,

Tobias




On 15/09/12 07:57, =JeffH wrote:
New rev:
https://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-13

please see change log excerpt included below for details. AFAIK this is ready for submission to IESG and IETF-wide Last Call.


full issue ticket list for strict-transport-sec:
<http://trac.tools.ietf.org/wg/websec/trac/query?status=assigned&status=closed&status=new&status=reopened&component=strict-transport-sec&order=id>

Redline spec diff from previous rev:
https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-websec-strict-transport-sec-13.txt

side-by-side diff from previous rev:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-websec-strict-transport-sec-13.txt


All issue tickets are closed.

Change Log for this rev is below.


=JeffH


==============================================================

Appendix D.  Change Log

   [RFCEditor: please remove this section upon publication as an RFC.]

   Changes are grouped by spec revision listed in reverse issuance
   order.

D.1.  For draft-ietf-websec-strict-transport-sec

      Changes from -12 to -13:

      1.  Addressed the IANA registry and IANA registry policy questions
          raised in Ben Campbel's Gen-ART LC review.  Selected "IETF
          Review" for IANA policy.  See the portion of this thread from
          this message onwards for details: <https://www.ietf.org/
          mail-archive/web/websec/current/msg01355.html>

      2.  Clarified the questions regarding max-age=0 interacting with
          includeSubdomains.  Expanded section 5.  HSTS Mechanism
          Overview, Added clarification text and forward ref to S 8.1
          from S 6.1.1.  Added two additional examples to S 6.2 which
          contain max-age=0.  See the thread rooted here for questions
          that informed this: <https://www.ietf.org/mail-archive/web/
          websec/current/msg01347.html>

      3.  upgraded ref to draft-ietf-dane-protocol to be to RFC6698.

      Changes from -11 to -12:

      1.  Addressed various issues in Ben Campbel's Gen-ART LC review.
          See this message for details: <https://www.ietf.org/
          mail-archive/web/websec/current/msg01324.html>

      Changes from -10 to -11:

<snip/>

---
end
_______________________________________________
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

--------------080609050206080105070307-- From trevp@trevp.net Wed Sep 26 06:36:49 2012 Return-Path: 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 DEFBC21F8862 for ; Wed, 26 Sep 2012 06:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 jOEeW72vMy5w for ; Wed, 26 Sep 2012 06:36:49 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2B821F8861 for ; Wed, 26 Sep 2012 06:36:49 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so666795vcb.31 for ; Wed, 26 Sep 2012 06:36:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=iYiexMoIYQOJ0NbJ8C7pqq2Mvigv5FMGCW7u1e7o/Jk=; b=eNbjGHjbfm3hljffa10OUd1sRyBZ+p9EKMkhLkPJAmLnkOVsUI4rWZQhKfF9LJsDWg yh2jSs6GejnzaQTyOYTaj7SuvIjllVqpC8Uhe853Aqz+th0HypIXwtch8tacV0Z7jL1Y sCBHLiHBHk1mmVa5YXNw+BUNhy+A2gPg8TV/hNFDJbcDUcc0qA8UlYjvid5m4tUaq6+w H6yo/wHVVBBTJnAc3EnywALJJqC5NNY0RxZv2MX5QTYWUvqkRGczFreZ0FxkgvMDeDVL 4XuJ0Iu+PMx2NnsU7vGjXZCntr7o2oiaDQjS+2z2RcDTsCSfOkbkldwXRp1Nrx/n93J1 nb7w== MIME-Version: 1.0 Received: by 10.220.154.6 with SMTP id m6mr253530vcw.51.1348666608497; Wed, 26 Sep 2012 06:36:48 -0700 (PDT) Received: by 10.52.24.36 with HTTP; Wed, 26 Sep 2012 06:36:48 -0700 (PDT) X-Originating-IP: [24.215.229.139] Date: Wed, 26 Sep 2012 09:36:48 -0400 Message-ID: From: Trevor Perrin To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm6uyFNchCzhzsuZ/2tP5YuQc2tht3iBJdBxIpi3FWadjf0StVmRbP9D0wUmbc5JRtvmSGG Cc: IETF WebSec WG Subject: [websec] TACK draft 01 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 13:36:50 -0000 Hi TLS (cc websec), There's a new TACK draft: http://tools.ietf.org/html/draft-perrin-tls-tack-01 You can find code and other resources at http://tack.io We'd love to get feedback or answer questions. We'd also appreciate advice on whether this should remain an individual submission or would make sense as a WG document. Changes -------- The main change is that we removed break signatures. Instead, servers may optionally publish a second tack. Clients can form two pins for a hostname. These changes let a server publish tacks from a new TACK key prior to deactivating and removing the old key's tacks. This "rollover" is a better way to handle a compromised or suspect TACK key because it preserves any security offered by the old key while the new one is being introduced. Other changes: * Rewrote "Client processing" to improve clarity. * Renamed "TACK" structure to "tack" "TACK_Extension" to "TackExtension" "pin_activation" field to "activation_flags" "TACK ID" to "key fingerprint" * Simplified error alerts sent by clients (and aligned with RFC 5878) * Deleted old section "6.2 Application-specific pinning", which was too vague to be useful. Added new 6.1 and 6.2 discussing considerations with different application protocols. * Changed server_name extension in ClientHello from SHOULD to SHALL. * Tweaked the Advice for Server Operators (8.1) regarding Tack expiration. Trevor From internet-drafts@ietf.org Sat Sep 29 14:23:43 2012 Return-Path: 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 955CF21F866B; Sat, 29 Sep 2012 14:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, 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 JrwfNPnGJeM0; Sat, 29 Sep 2012 14:23:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D7321F8670; Sat, 29 Sep 2012 14:23:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120929212343.17377.11124.idtracker@ietfa.amsl.com> Date: Sat, 29 Sep 2012 14:23:43 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-strict-transport-sec-14.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 21:23:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Security Working Group of the IETF. Title : HTTP Strict Transport Security (HSTS) Author(s) : Jeff Hodges Collin Jackson Adam Barth Filename : draft-ietf-websec-strict-transport-sec-14.txt Pages : 54 Date : 2012-09-29 Abstract: This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections, and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field, and/or by other means, such as user agent configuration, for example. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport-sec There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-strict-transport-sec-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/