From gerv@mozilla.org Thu Aug 1 01:29:25 2013 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 C257921F9DBD for ; Thu, 1 Aug 2013 01:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQy81UMVZ8kW for ; Thu, 1 Aug 2013 01:29:18 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCF621F940D for ; Thu, 1 Aug 2013 01:28:38 -0700 (PDT) Received: from [192.168.0.101] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 231CDF22C2; Thu, 1 Aug 2013 01:28:35 -0700 (PDT) Message-ID: <51FA1C35.1090005@mozilla.org> Date: Thu, 01 Aug 2013 09:28:37 +0100 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yoav Nir References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> In-Reply-To: <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 01 Aug 2013 08:29:25 -0000 On 31/07/13 21:33, Yoav Nir wrote: > This issue turned out to be more contentious that I had expected. > We've had two people in support of the change, in addition to one > response that seems to indicate support for such a change, and Mark's > remarks at the meeting, which were also kind-of, sort-of in support > of such a change. > > This does not look to me like consensus to keep the status quo. Do > others feel differently? If so, please speak up soon. The Mozilla team working on CSP went back and forth on a related question - that of whether the header should contain the policy, or a URI to a file containing the policy, or have the option of doing both. We eventually decided that having it only in the header was OK, although I cannot now find a document which lays out the reasoning. However, I would be happy to ask someone. Obviously, a well-known URI has the advantage of not having to be sent for every request. But it has the disadvantage that (unless you make the file format syntax complex) there's only one policy per domain, the browser has to cache the information, and it's an extra HTTP request on every connection to a new site (because you can't know the file is there until you look for it). I suspect that has performance implications. Gerv From trevp@trevp.net Thu Aug 1 01:50:18 2013 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 BBC6F21F9E9F for ; Thu, 1 Aug 2013 01:50:18 -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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WD4fhxA0yOoB for ; Thu, 1 Aug 2013 01:50:11 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id B0C1D21F9E88 for ; Thu, 1 Aug 2013 01:50:07 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id j13so1407016wgh.26 for ; Thu, 01 Aug 2013 01:50:05 -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:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=GeMxiG0Rb3IOWQZ3E2JROQWqqOHvfBT4CMRozjCh33Y=; b=I9xK6hsYYij3eemM9YKNWGOP8IuF0sjPy40CV8ivEQAcpm5xw9QgPfAvcl5Td9ugW6 avg+zlQ9rd2/9L3Q0eTXPtXwUQWApWTL57fqLp3p/hVCTrjLkVPaWcISH8O/tJQ3KSw5 Yx4H7/dQH10boa/K0QUjjwyulsZU5l+x62Gprcrr+Vx5xpjrz1W3yadXJIo6zrKDxMyC y/Fb55A7tH8aifkI0ADT3tCfBXgprXZnzD0lU0JnCsHuJ1rNeMyJyvt94vEETF2PP/Gv tbHZZ2rvwNLmFwZfMzLYCKWVgPhquh6pIxoBenf3+MEhnvfnvVz3aVzX4ChKu/ovcNuO Kzkw== MIME-Version: 1.0 X-Received: by 10.180.10.202 with SMTP id k10mr388647wib.17.1375347005672; Thu, 01 Aug 2013 01:50:05 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Thu, 1 Aug 2013 01:50:05 -0700 (PDT) X-Originating-IP: [24.120.221.55] In-Reply-To: <51FA1C35.1090005@mozilla.org> References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> <51FA1C35.1090005@mozilla.org> Date: Thu, 1 Aug 2013 01:50:05 -0700 Message-ID: From: Trevor Perrin To: Gervase Markham Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkD9sGH8ay0xAGSP/U2z3zX+TQUwM5ltDEZqsOaGVPDIqBK5QV+gMVTmVJrSZhoaKbxluo2 Cc: IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 01 Aug 2013 08:50:18 -0000 On Thu, Aug 1, 2013 at 1:28 AM, Gervase Markham wrote: > On 31/07/13 21:33, Yoav Nir wrote: >> This issue turned out to be more contentious that I had expected. >> We've had two people in support of the change, in addition to one >> response that seems to indicate support for such a change, and Mark's >> remarks at the meeting, which were also kind-of, sort-of in support >> of such a change. >> >> This does not look to me like consensus to keep the status quo. Do >> others feel differently? If so, please speak up soon. > > The Mozilla team working on CSP went back and forth on a related > question - that of whether the header should contain the policy, or a > URI to a file containing the policy, or have the option of doing both. > > We eventually decided that having it only in the header was OK, although > I cannot now find a document which lays out the reasoning. However, I > would be happy to ask someone. Hi Gerv, CSP is quite different from HPKP, isn't it? CSP needs to be delivered with the page it's being applied to. It can't be fetched asynchronously, but that's fine for HPKP. Also, CSP applies to particular resources, whereas TLS-layer checks are applied to the hostname. So I don't think CSP's reasoning for header vs URI is going to translate that well. Also, to Yoav and Tobias's point - I don't think it would ever make sense to combine CSP and HPKP in a single .well-known URI. However, I'm not sure about naming the file so specifically as "PublicKeyPinning", as Yoav proposes. That implies that it can't be extended to contain related data, they would need their own URIs. Joe Bonneau has used the term "transport security policy" to refer to policies like pinning assertions for HSTS, HPKP, TACK, opt-in to CT or DNSSEC/DANE, etc. It seems reasonable that we might want more "transport security policies" for these things in the future. If that happens, I don't see why we'd want the browser to make separate requests for each one. So I'd prefer a more generic name like "transport_security_policy.json", and explicitly allowing such extensibility. Trevor From ynir@checkpoint.com Thu Aug 1 01:59:34 2013 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 7CF4521F9F00 for ; Thu, 1 Aug 2013 01:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tnn2zsZVVCF4 for ; Thu, 1 Aug 2013 01:59:28 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id F2FBF21F9EF8 for ; Thu, 1 Aug 2013 01:59:26 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r718xOjq004492; Thu, 1 Aug 2013 11:59:24 +0300 X-CheckPoint: {51FA236C-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Thu, 1 Aug 2013 11:59:23 +0300 From: Yoav Nir To: Gervase Markham Thread-Topic: [websec] #60: Well Known URIs vs Response Headers Thread-Index: AQHOjJuYwSHLWJ6FxEGQqE9b5vLwWJl77USAgAD8uoCAAiUAAIAAx7yAgAAImAA= Date: Thu, 1 Aug 2013 08:59:23 +0000 Message-ID: <4B4A645A-793F-4276-96BF-FBA5BA740632@checkpoint.com> References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> <51FA1C35.1090005@mozilla.org> In-Reply-To: <51FA1C35.1090005@mozilla.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.100] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 112f5fcec62f41ca2c1949316cc1aa1c1453137da7 Content-Type: text/plain; charset="us-ascii" Content-ID: <26D891E958797248953856C36574FB4F@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 01 Aug 2013 08:59:34 -0000 On Aug 1, 2013, at 10:28 AM, Gervase Markham wrote: > On 31/07/13 21:33, Yoav Nir wrote: >> This issue turned out to be more contentious that I had expected. >> We've had two people in support of the change, in addition to one >> response that seems to indicate support for such a change, and Mark's >> remarks at the meeting, which were also kind-of, sort-of in support >> of such a change. >>=20 >> This does not look to me like consensus to keep the status quo. Do >> others feel differently? If so, please speak up soon. >=20 > The Mozilla team working on CSP went back and forth on a related > question - that of whether the header should contain the policy, or a > URI to a file containing the policy, or have the option of doing both. >=20 > We eventually decided that having it only in the header was OK, although > I cannot now find a document which lays out the reasoning. However, I > would be happy to ask someone. Thanks for the information. It is interesting that this was considered, but= maybe some of the disadvantages you cite below apply to CSP more than to H= PKP. > Obviously, a well-known URI has the advantage of not having to be sent > for every request. But it has the disadvantage that (unless you make the > file format syntax complex) there's only one policy per domain, the > browser has to cache the information, and it's an extra HTTP request on > every connection to a new site (because you can't know the file is there > until you look for it). I suspect that has performance implications. One policy per domain is find for HPKP (also for HSTS), but CSP has some di= rective that may be page-specific (font-src ?) Thanks again. Yoav From tobias.gondrom@gondrom.org Thu Aug 1 02:13:29 2013 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 D2E7E21F9CF3 for ; Thu, 1 Aug 2013 02:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.054 X-Spam-Level: X-Spam-Status: No, score=-96.054 tagged_above=-999 required=5 tests=[AWL=-0.692, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTY-HTeCD8t8 for ; Thu, 1 Aug 2013 02:13:24 -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 2B60B21F9C10 for ; Thu, 1 Aug 2013 02:13:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=Rr4l4aXwgNCI31UjdJ+P5BD6MLK8tK7B9327wgkBY8LlFeoZ60yjSKP6iljXgj+zF7CDhDZBC/f29zGMYFvEX9HBJi11BvAF9IhtQv9u7DjLOahX1yPeBgaANSefBGj8; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 1428 invoked from network); 1 Aug 2013 11:13:19 +0200 Received: from dhcp-411f.meeting.ietf.org (HELO ?130.129.65.31?) (130.129.65.31) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 1 Aug 2013 11:13:19 +0200 Message-ID: <51FA26AD.2020405@gondrom.org> Date: Thu, 01 Aug 2013 11:13:17 +0200 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: ynir@checkpoint.com References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> <51FA1C35.1090005@mozilla.org> <4B4A645A-793F-4276-96BF-FBA5BA740632@checkpoint.com> In-Reply-To: <4B4A645A-793F-4276-96BF-FBA5BA740632@checkpoint.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 01 Aug 2013 09:13:30 -0000 On 01/08/13 10:59, Yoav Nir wrote: > On Aug 1, 2013, at 10:28 AM, Gervase Markham wrote: > >> On 31/07/13 21:33, Yoav Nir wrote: >>> This issue turned out to be more contentious that I had expected. >>> We've had two people in support of the change, in addition to one >>> response that seems to indicate support for such a change, and Mark's >>> remarks at the meeting, which were also kind-of, sort-of in support >>> of such a change. >>> >>> This does not look to me like consensus to keep the status quo. Do >>> others feel differently? If so, please speak up soon. >> The Mozilla team working on CSP went back and forth on a related >> question - that of whether the header should contain the policy, or a >> URI to a file containing the policy, or have the option of doing both. >> >> We eventually decided that having it only in the header was OK, although >> I cannot now find a document which lays out the reasoning. However, I >> would be happy to ask someone. > Thanks for the information. It is interesting that this was considered, but maybe some of the disadvantages you cite below apply to CSP more than to HPKP. > >> Obviously, a well-known URI has the advantage of not having to be sent >> for every request. But it has the disadvantage that (unless you make the >> file format syntax complex) there's only one policy per domain, the >> browser has to cache the information, and it's an extra HTTP request on >> every connection to a new site (because you can't know the file is there >> until you look for it). I suspect that has performance implications. > One policy per domain is find for HPKP (also for HSTS), but CSP has some directive that may be page-specific (font-src ?) Actually CSP is per se page specific - which is reflected in many parts of the policy. So one policy URL for every resource on a server would not work IMHO. Best regards, Tobias > > Thanks again. > > Yoav > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From gerv@mozilla.org Thu Aug 1 07:21:58 2013 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 947DB21E818B for ; Thu, 1 Aug 2013 07:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVYqOk-D+3gv for ; Thu, 1 Aug 2013 07:21:52 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id A230821E81EC for ; Thu, 1 Aug 2013 07:21:24 -0700 (PDT) Received: from [192.168.0.101] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id F3F31F223B; Thu, 1 Aug 2013 07:21:22 -0700 (PDT) Message-ID: <51FA6EE4.9040007@mozilla.org> Date: Thu, 01 Aug 2013 15:21:24 +0100 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yoav Nir References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> <51FA1C35.1090005@mozilla.org> In-Reply-To: <51FA1C35.1090005@mozilla.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 01 Aug 2013 14:21:58 -0000 On 01/08/13 09:28, Gervase Markham wrote: > On 31/07/13 21:33, Yoav Nir wrote: >> This issue turned out to be more contentious that I had expected. >> We've had two people in support of the change, in addition to one >> response that seems to indicate support for such a change, and Mark's >> remarks at the meeting, which were also kind-of, sort-of in support >> of such a change. >> >> This does not look to me like consensus to keep the status quo. Do >> others feel differently? If so, please speak up soon. Further input from one of our network library engineers: "From a networking performance point of view we would much rather have smallish redundant header data (anything smaller than the order of magnitude of uris and cookies is effectively smallish) than to be initiating additional out of band transactions. I also think there are timing issues here - the argument is that the oob fetch is non-blocking because it only applies to the next connection - but "next connection" and "async oob" are not necessarily strictly ordered - especially when we're really busy or the network is performing poorly. There are all sorts of pieces of server information that would be interesting in a well-known uri (including many non security oriented ones) - lets not go building a fetch-and-persistently-cache model separately for each one of them. An integrated effort would be much more interesting." Gerv From palmer@google.com Thu Aug 1 09:24:40 2013 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 B7A3A21F9CDA for ; Thu, 1 Aug 2013 09:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWgAWrIJzfAl for ; Thu, 1 Aug 2013 09:24:39 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 873B611E810A for ; Thu, 1 Aug 2013 09:24:36 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id h1so1876199oag.10 for ; Thu, 01 Aug 2013 09:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N5UuKdh3IAhEmgV6atjEVoRHQcnULNv/LmzO9qGa2BY=; b=lPwEyYoo4JBy4oOI8Q2GCMu2PiEH0z21w91dcx4sp3snnUpV67MExMNqda81z10mTH bSX34B3Hl/DdNQdR2JBKAbZEsX4ExfO88WGZyBO4FNLiJFsCQbxY/7VU4ejMRg58gNYj RwSf8kQOyOm1tEdI0/tfc0aSOyGQux80WnkEvXKeVxn3k0P4FGW+o8cjlKLn66e+SjbZ cwBWpl3UzkGFdSAMNT69+O8dJ3PxCYUSAYP+VkohzxgJsJvxI5RqLPoyrtw+cYvKIYA9 HC+nn9bMVlbkrFUdlTH8eQXDgJZcX+0mWXSaiuMsTFnq4HWxMHV8Knbr2bLjsB7mXTg3 nNXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=N5UuKdh3IAhEmgV6atjEVoRHQcnULNv/LmzO9qGa2BY=; b=RLUwqF26HIXn5cdSy4xl3sJGPIbUL0PY8jBc5WrKFAQpwfG0obvQ6/n+2OovLRYBtW LeltBNpQB/SHaLFAH58+Q3e166FaoByy0qmwMVZyRmuSLJ0gg5raL4Vn+1rUm1OiGFSl 8hngkMXiut7RpWnswZFTT6V5q68OgXM2dc43ouvZNBZ2g0b5jpgB3QWVz/UGU28dNHFS v34Xi6cUxjf4hhEuaiYrZgoZvfrasHRCaeU2WHwksLjLzDljlhz9DdMosbmt+wop5C+a RCC5NkKgE5SMZnoMjLaYDbdbAHgby+bHlHxuyKNRBFAhWIFlurqubSS7RQhYROW9llUr kvBA== MIME-Version: 1.0 X-Received: by 10.50.11.102 with SMTP id p6mr1320107igb.49.1375374275687; Thu, 01 Aug 2013 09:24:35 -0700 (PDT) Received: by 10.64.240.71 with HTTP; Thu, 1 Aug 2013 09:24:35 -0700 (PDT) In-Reply-To: <51FA26AD.2020405@gondrom.org> References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> <51FA1C35.1090005@mozilla.org> <4B4A645A-793F-4276-96BF-FBA5BA740632@checkpoint.com> <51FA26AD.2020405@gondrom.org> Date: Thu, 1 Aug 2013 09:24:35 -0700 Message-ID: From: Chris Palmer To: Tobias Gondrom Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmw6o1oIY93EC0on+eNgivq5fCkB46fxzqEDnL7xQUAbtx5cke640258Iguj6LUeEBE4LxUuLoEzR4NSE/j50nALRT9Qa0x5c+zkczEOPeJliYIAboOQrDLXwfjoS5msUQa28gJNSYXasqkwhEMiMHBlxct8mGQ7F4Ewypx2UyLt0+dc3XoBsRHEt3SOXbSn1zOahQo Cc: IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 01 Aug 2013 16:24:40 -0000 I wish people had expressed their strong desire for a W-K URI earlier. Previously, there was an apparently weak desire, but suddenly now that we're in last call it's a big issue. Recall that pinning was intended to be a quick and easy extension of HSTS before Certificate Transparency landed... Here is an attempt to summarize what's going on. * """For example, if the administrators of https://example.net/ allow the user foo to publish arbitrary content below https://example.net/~foo/, and that user emits an HPKP header, they could potentially override the backup pins offered by the site administrator, ...""" No, the same-origin policy is defined such that paths are not part of the origin. Thus, code in https://example.net/~foo/ already has complete control over the entire (https, example.net, 443) origin. * Regarding generic security policy URI: If we can't achieve consensus in this WG, why would adding dependencies on more WGs and W3C help? Obviously, it would not. Thus, we should stick to defining only pinning policy in this draft. I don't expect that we will ever have a generic security policy W-K URI, so that cannot be a reason to support moving HPKP to a W-K URI. It does make more sense to try to make it generic to transport security, but even then, it's optional and Jeff Hodges might be tired and might not want to specify JSON syntax for HSTS... Jeff? And it doesn't make much sense to put TACK policy in the resource, does it? TACK is all at the TLS layer. * "possibly dozens of hashes": As we can see from Chrome's net/http/transport_security_state_static.json, Twitter does indeed trust a huge number of signers in its static key pins. I hope that Twitter is an outlier in this, and that sites don't start needing to trust so many signers. (Google uses fewer pins, for example.) But, maybe not, and maybe header bloat will become a concern. (Even so, wake me up when response body bloat is no longer a concern...) But we can resolve that problem with trust anchor names in place of SPKIs just as easily as with a W-K URI. * We could also relax the requirement to send the PKP header on each response. To be honest I can't recall now why we required it, but it seems like it resolved some security concern? Maybe it's in the archives... * """caching: With a well-known URI, there are probably still caching issues to stake out; how often should a browser update its security policy for a given site in the absence of standard HTTP caching headers from the server? Or is it a MUST that the well-known URI needs to publish caching headers?""" We could simply get rid of max-age, and have the policy apply for however long the resource is defined to be valid (with cache control headers). I would say that site operators SHOULD set good cache control headers for *all* their resources. From palmer@google.com Thu Aug 1 09:30:36 2013 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 504E921E819C for ; Thu, 1 Aug 2013 09:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFKU3SsTcn21 for ; Thu, 1 Aug 2013 09:30:35 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 509B021E818D for ; Thu, 1 Aug 2013 09:30:15 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id xn12so4243354obc.20 for ; Thu, 01 Aug 2013 09:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pOrX/QdhxZ8CA9r8FuTOHzNurmT55uOS27Y+xV18lSE=; b=Fh+Pl47P8iL7qElBjcj5ijip49BLHUQG2+3rY6xP0pvn/Rgv3N1sK5Wln135tF1UKy sIQVF+iGTPoTXybad3WZBkl9aQ3WwPupJGhmkHgbMftLk694KfsRiwGbb9bs0f1v8GXc HuxYXhZT14gL5UMYpxidEvoJjThccnW2ylwRDUoqr0OvIgnVgOU/N0GKl3IHe96YY9xT rnW2qe+ghjgWTY1i2Z7+LCTiLA7yrSYi71X3GKL+VnHyKG6//I/KgEVruNcxMyiiOEGr A2a8vGUQe7DFxBVoTvP2jJSksspabsVNUdBcMYKDoDgwxf0nmajHA1wHThLcmxedlOdX lRWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=pOrX/QdhxZ8CA9r8FuTOHzNurmT55uOS27Y+xV18lSE=; b=QqHdFyS7H7/aYga1NWWj5D+KEW5RhRkXM4A1B85qsCsZ8QXLogq93pXXRr2A+meo9Z 5IH5uhnTruiR+mlnmYpSVOYuCnYafynG+ISD+iuPaoxhEeCIOoLV8cVsZqgusA3lN3Jf cZ+ljAooDNGgRpQPzH5BlIC7NJZdZBtx84beB2qNCqvimu2S9tHn4KwYLJfmMBh3Txs2 s9SurjgUkN8Fy5AvKzp+gVaGZbskmYJZ7Xvttr5ID4mIlEmhjj43RckGTfmfqqnwk252 AUC+19yyk4CwgpKTfOU6WuKicGaluEdhNBYAmQnvez8z1oUba8Mzc4eMo3LnG2TH4723 8ulw== MIME-Version: 1.0 X-Received: by 10.50.128.19 with SMTP id nk19mr1369417igb.1.1375374613973; Thu, 01 Aug 2013 09:30:13 -0700 (PDT) Received: by 10.64.240.71 with HTTP; Thu, 1 Aug 2013 09:30:13 -0700 (PDT) In-Reply-To: References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> Date: Thu, 1 Aug 2013 09:30:13 -0700 Message-ID: From: Chris Palmer To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnwQUfPm3jQG20hYJLiXAVUuAjViL4/PFN7731jvMmRjImCKwezVrZZFOehuiBhfx2s/SP1LKF0vybRVYMxmNLWajwaaJEui5pPbN/d3SXfG5PFOPmApjD9NbG5V8W/zEEEfJ8xNLZ9p+F0SrRYMHf9NJuccGbaWZmkc3ReUCa6uAmu3GEXll6yfXaQ20YL7gRxJL3c Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 01 Aug 2013 16:30:36 -0000 On Mon, Jul 29, 2013 at 9:13 AM, Phillip Hallam-Baker wrote: > If we have a diginotar type situation again (FSM forefend), we want the pins > to a root to be broken at the same time the root is unloaded, yes? If the root of a site's cert chain --- really, any signer --- is blacklisted or even just removed from the trust anchor store, pins and Pin Validation are irrelevant since the chain won't validate. Pin Validation happens only *after* all other certificate chain checks are performed. > The trust anchor data structures are outside the PKIX model but they browser > providers do need to track them regardless. I would rather tie pins to the > actual entity we want to pin to (the CA) rather than attempt pinning to some > sort of proxy. Allowing sites to pin to any point in the certificate chain is a feature, not a bug. However, it will almost always make the most sense to pin to one or more CAs. Thus, making that easy is a good goal. > There are CAs that are not represented in CABForum but CABForum is a place > where we can get a requirement of the form 'every CA must pick a DNS name as > a unique identifier for their service and report it to the browser > providers'. And that requirement will quickly become universal. > > While we could choose a different string, Paul H.'s argument for using DNS > names in CAA was a good one and I can't see any advantage to inconsistency. > It also makes it much easier to make any scheme work with a private CA. Agreed. From hallam@gmail.com Thu Aug 1 09:43:04 2013 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 571A521E81FE for ; Thu, 1 Aug 2013 09:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvDM38MSaH7J for ; Thu, 1 Aug 2013 09:43:03 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DC1E421E815C for ; Thu, 1 Aug 2013 09:43:02 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q58so1910901wes.20 for ; Thu, 01 Aug 2013 09:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ndtluZJaygNZWXWYCEpoOigo1y+NZO+Ld/nOP1ZPkYQ=; b=Jp4CcGD8E231QJ/DbOIQQ9RpWuE61KXubNvDh9SWM8ModOcPVAN+ZPCceKnePJ6tuC W1nJakt99hdxrocTmYkl3OF0/tibzcGmbvVaDal3j0+d242tPgWJec4TSBZnArYivl60 6cBCBc8+gnjJs4gZahT8Rh9hvKL4gK+V89c1ldGa4pbuFsHe0kbcsniXKLn36Du8OHZL 3kCxfAYfi4qbssvVd0e/J4cbSjCszxKfafoH3vWg5iq7PY22JuQzLVZ/l4u+I7fMGgqg NnKTRbiJamBVxsrpW2CwnYw0gKoNtJ3IsZw4BO6pzl0h6hwe/R7vrrtvIUBQ51tM9F8t XD9w== MIME-Version: 1.0 X-Received: by 10.180.182.229 with SMTP id eh5mr1787265wic.63.1375375381743; Thu, 01 Aug 2013 09:43:01 -0700 (PDT) Received: by 10.194.6.67 with HTTP; Thu, 1 Aug 2013 09:43:01 -0700 (PDT) In-Reply-To: References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> Date: Thu, 1 Aug 2013 12:43:01 -0400 Message-ID: From: Phillip Hallam-Baker To: Chris Palmer Content-Type: multipart/alternative; boundary=089e0163491e0fd25704e2e58977 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 01 Aug 2013 16:43:04 -0000 --089e0163491e0fd25704e2e58977 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 1, 2013 at 12:30 PM, Chris Palmer wrote: > On Mon, Jul 29, 2013 at 9:13 AM, Phillip Hallam-Baker > wrote: > > > If we have a diginotar type situation again (FSM forefend), we want the > pins > > to a root to be broken at the same time the root is unloaded, yes? > > If the root of a site's cert chain --- really, any signer --- is > blacklisted or even just removed from the trust anchor store, pins and > Pin Validation are irrelevant since the chain won't validate. Pin > Validation happens only *after* all other certificate chain checks are > performed. My point is that the people who were customers of Diginotar had to get new certs quickly. The Dutch government has complained in several forums about the way in which the Diginotar root was revoked. They had an entire national port unable to function as a result. If the root is revoked, the pins have to become inoperable and allow a user to get a cert from any vendor. Continuity of business is an issue here. -- Website: http://hallambaker.com/ --089e0163491e0fd25704e2e58977 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 1, 2013 at 12:30 PM, Chris Palmer <= ;palmer@google.com> wrote:
On Mon, Jul 29, 2013 at 9:= 13 AM, Phillip Hallam-Baker <hallam@= gmail.com> wrote:

> If we have a diginotar type situation again (FSM forefend), we want th= e pins
> to a root to be broken at the same time the root is unloaded, yes?

If the root of a site's cert chain --- really, any signer --- is<= br> blacklisted or even just removed from the trust anchor store, pins and
Pin Validation are irrelevant since the chain won't validate. Pin
Validation happens only *after* all other certificate chain checks are
performed.

My point is that the people who = were customers of Diginotar had to get new certs quickly. The Dutch governm= ent has complained in several forums about the way in which the Diginotar r= oot was revoked. They had an entire national port unable to function as a r= esult.

If the root is revoked, the pins have to become inopera= ble and allow a user to get a cert from any vendor.=A0

=

Continuity of business is an issue here.=A0
<= br>

--
Website: http://hallambaker.com/
--089e0163491e0fd25704e2e58977-- From ynir@checkpoint.com Thu Aug 1 18:04:54 2013 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 641CC11E82BF for ; Thu, 1 Aug 2013 18:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.474 X-Spam-Level: X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gF1lnmpB3Bmf for ; Thu, 1 Aug 2013 18:04:42 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF1D11E82D6 for ; Thu, 1 Aug 2013 17:06:03 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7205qdh014832; Fri, 2 Aug 2013 03:05:52 +0300 X-CheckPoint: {51FAF7E0-A-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Fri, 2 Aug 2013 03:05:52 +0300 From: Yoav Nir To: Phillip Hallam-Baker Thread-Topic: [websec] #58: Should we pin only SPKI, or also names Thread-Index: AQHOjHagv3/BmvZ4wU6WrbkIw+Bd/ZmAXZOAgAADk4CAAHu6gA== Date: Fri, 2 Aug 2013 00:05:51 +0000 Message-ID: <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.134] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 118462de19621d1f8003d384449cd3b5ae46852d01 Content-Type: multipart/alternative; boundary="_000_6125A8416C854858B37FC021067F0CFAcheckpointcom_" MIME-Version: 1.0 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 02 Aug 2013 01:04:54 -0000 --_000_6125A8416C854858B37FC021067F0CFAcheckpointcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Aug 1, 2013, at 6:43 PM, Phillip Hallam-Baker > wrote: On Thu, Aug 1, 2013 at 12:30 PM, Chris Palmer > wrote: On Mon, Jul 29, 2013 at 9:13 AM, Phillip Hallam-Baker > wrote: > If we have a diginotar type situation again (FSM forefend), we want the p= ins > to a root to be broken at the same time the root is unloaded, yes? If the root of a site's cert chain --- really, any signer --- is blacklisted or even just removed from the trust anchor store, pins and Pin Validation are irrelevant since the chain won't validate. Pin Validation happens only *after* all other certificate chain checks are performed. My point is that the people who were customers of Diginotar had to get new = certs quickly. The Dutch government has complained in several forums about = the way in which the Diginotar root was revoked. They had an entire nationa= l port unable to function as a result. If the root is revoked, the pins have to become inoperable and allow a user= to get a cert from any vendor. To me this seems too hard for the browser. This is especially true if the p= ins were for a sub-CA rather than the root CA. Continuity of business is an issue here. Yes, it is. That is what the backup pin feature is for, and why it is manda= tory in the draft. Yoav --_000_6125A8416C854858B37FC021067F0CFAcheckpointcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <4931289A1A9A88499E588B6C77080A4E@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable
On Aug 1, 2013, at 6:43 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:




On Thu, Aug 1, 2013 at 12:30 PM, Chris Palmer <palmer@google.co= m> wrote:
On Mon, Jul 29, 2013 at 9:13 AM, Phillip Hallam-Baker <= ;hallam@gmail.com> wrote:

> If we have a diginotar type situation again (FSM forefend), we want th= e pins
> to a root to be broken at the same time the root is unloaded, yes?

If the root of a site's cert chain --- really, any signer --- is
blacklisted or even just removed from the trust anchor store, pins and
Pin Validation are irrelevant since the chain won't validate. Pin
Validation happens only *after* all other certificate chain checks are
performed.

My point is that the people who were customers of Diginotar had to get= new certs quickly. The Dutch government has complained in several forums a= bout the way in which the Diginotar root was revoked. They had an entire na= tional port unable to function as a result.

If the root is revoked, the pins have to become inoperable and allow a= user to get a cert from any vendor. 

To me this seems too hard for the browser. This is especially true if the p= ins were for a sub-CA rather than the root CA.

Continuity of business is an issue here. 

Yes, it is. That is what the backup pin feature is for, and why it is manda= tory in the draft.

Yoav

--_000_6125A8416C854858B37FC021067F0CFAcheckpointcom_-- From trevp@trevp.net Thu Aug 1 18:40:06 2013 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 2B41111E8167 for ; Thu, 1 Aug 2013 18:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcuxpNunAc+J for ; Thu, 1 Aug 2013 18:39:53 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id CC2B411E8311 for ; Thu, 1 Aug 2013 17:51:24 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id m15so31533wgh.17 for ; Thu, 01 Aug 2013 17:51:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WkdZZ9LfdKFJQtsbq7SOnrfKNA3qwJKou/FTWp7AQ1A=; b=FmaQKBhiVTpyFl4Ew4JbV/uw2yTY4wBqCWgwuZJHBSIejPCXZmeJY3N7l2hf5GBd38 gnP//z6RFv7SfxXSBsqR6D4AuR7QSOi5ZxhF1DE0OShObumqRQBTTlqflFumNS4ORe27 yVGdDnaWe0FyOQ5HlRBc6Cs/ydTACcYk7Ks+SAENfIwiQcyItIue5z9W1uajy9t92Yj5 iVQhvPxECuLhBdaEF7vGnd5KKjNlczXoHiNwEw91zfvvw9gKLkv6NuC2huPPZsWx61Ie IYCygrt1k9HB4TuQ/h9M0URNTySpazsL8gqUHexSOJoP9X242o5CFNUFAhgCxZiFO/XM siDw== X-Gm-Message-State: ALoCoQmjkeihv6X4b/FywEBRXljLx/VQBM54exObJX/WvwkYBUuyraJvTBDrDvm7CS9YwHyFhw/l MIME-Version: 1.0 X-Received: by 10.180.100.225 with SMTP id fb1mr174623wib.22.1375404668153; Thu, 01 Aug 2013 17:51:08 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Thu, 1 Aug 2013 17:51:08 -0700 (PDT) X-Originating-IP: [204.62.111.55] In-Reply-To: References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> <51FA1C35.1090005@mozilla.org> <4B4A645A-793F-4276-96BF-FBA5BA740632@checkpoint.com> <51FA26AD.2020405@gondrom.org> Date: Thu, 1 Aug 2013 17:51:08 -0700 Message-ID: From: Trevor Perrin To: Chris Palmer Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 02 Aug 2013 01:40:06 -0000 On Thu, Aug 1, 2013 at 9:24 AM, Chris Palmer wrote: > * Regarding generic security policy URI: If we can't achieve consensus > in this WG, why would adding dependencies on more WGs and W3C help? > Obviously, it would not. Thus, we should stick to defining only > pinning policy in this draft. Definitely. > It does make more sense to try to make it > generic to transport security, but even then, it's optional and Jeff > Hodges might be tired and might not want to specify JSON syntax for > HSTS... Jeff? If we go the .well-known URI route, it might as well be extensible to "similar things", though I agree we shouldn't spend effort on them now. > And it doesn't make much sense to put TACK policy in the > resource, does it? TACK is all at the TLS layer. It might make sense, at some point. TACK is mainly just a key that can be pinned. TACK has its own way of asserting pins (setting an "activation flag"). But if you leave the flag cleared then a tack is just a signing key and signature. Other layers could assert pins to the signing key, perhaps to add features like HPKP's "report-URI" or "strict" or something. Not saying that's a great idea, but it's not crazy... > * "possibly dozens of hashes": As we can see from Chrome's > net/http/transport_security_state_static.json, Twitter does indeed > trust a huge number of signers in its static key pins. I hope that > Twitter is an outlier in this, and that sites don't start needing to > trust so many signers. (Google uses fewer pins, for example.) They may be an outlier, but we don't really know. Sites might want very safe pins that list several CAs, so they have backup options. And apparently some CAs have several keys (11 for Verisign? 7 for GeoTrust?) > But, > maybe not, and maybe header bloat will become a concern. (Even so, > wake me up when response body bloat is no longer a concern...) But we > can resolve that problem with trust anchor names in place of SPKIs > just as easily as with a W-K URI. Agreed. If we had to solve this one way or the other, I'd prefer to do pinning CA names, because I think it solves a bigger useability problem for sites. > * We could also relax the requirement to send the PKP header on each > response. To be honest I can't recall now why we required it, but it > seems like it resolved some security concern? Maybe it's in the > archives... I don't recall it being discussed. I do think this requirement could be relaxed. Trevor From jbonneau@gmail.com Sat Aug 3 14:33:55 2013 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 69FFF21F991F for ; Sat, 3 Aug 2013 14:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpZe8Kfk87F3 for ; Sat, 3 Aug 2013 14:33:54 -0700 (PDT) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id B6B4021F9AD8 for ; Sat, 3 Aug 2013 14:33:51 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id ox1so1952140veb.9 for ; Sat, 03 Aug 2013 14:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2R0aJkYHoW/DRYsMsdlRbL7ebpxFRVeb2obo8uwFm2I=; b=dgrSAG4I0Vli71hjm0GB4DYIkssB6Fsy3NAJguqpU/sqC+XOXWE8Tm1mlW77PSRxvR LD/sBA5W0eXBuwQXT2bR+pyCochTyVDcrxh1gNeEJq30He7ojX7jJ0tx3PQTsBQTabyo 0iIRWi3wrA58o3RTg7MAiar44TIhjDhwuFtd+lxCSlhMlFASUjHoafWIcA73CLXtRVM/ 35xXNfmBQQSM7hcoZd9RSb8qE2Kogx8XXMvmtb0HaCtLszpD2hfnzcoAR2UueukUXPKb 80yDRRsNgQMbPU3QUgA2eaxhDXE9QXY44pnhTtnmjGu2VBcEVHXIbgT/2Pd1ir/V0VBz OEjA== X-Received: by 10.52.73.229 with SMTP id o5mr3212579vdv.54.1375565631182; Sat, 03 Aug 2013 14:33:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.62.73 with HTTP; Sat, 3 Aug 2013 14:33:31 -0700 (PDT) In-Reply-To: References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> <51FA1C35.1090005@mozilla.org> <4B4A645A-793F-4276-96BF-FBA5BA740632@checkpoint.com> <51FA26AD.2020405@gondrom.org> From: Joseph Bonneau Date: Sat, 3 Aug 2013 17:33:31 -0400 Message-ID: To: Trevor Perrin Content-Type: multipart/alternative; boundary=bcaec5014df7cfe05004e311d473 Cc: IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 03 Aug 2013 21:33:55 -0000 --bcaec5014df7cfe05004e311d473 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 1, 2013 at 8:51 PM, Trevor Perrin wrote: > On Thu, Aug 1, 2013 at 9:24 AM, Chris Palmer wrote: > > * Regarding generic security policy URI: If we can't achieve consensus > > in this WG, why would adding dependencies on more WGs and W3C help? > > Obviously, it would not. Thus, we should stick to defining only > > pinning policy in this draft. > > Definitely. I agree it wouldn't make sense to bog-down the HPKP spec with HSTS (and definitely not CSP). I think the question is, for the next HTTPS policy that sites may want to declare, can we make it as easy to do so as possible? CT is the right test case here because IMO it will be very useful to set a CT-required bit. If refactoring the HPKP spec to a well-known URI enables CT to push this through in a few months instead of a year, that's a nice benefit though still not the main motivation for switching to a well-known URI. > They may be an outlier, but we don't really know. Sites might want > very safe pins that list several CAs, so they have backup options. > And apparently some CAs have several keys (11 for Verisign? 7 for > GeoTrust?) > Another way of looking at this is, how can the spec be written to minimally disincentivize sites from adopting it? If sites want to pin but feel they can't deploy a pinning policy with less than Twitter's 19 hashes, and they have to add that to every response, some percentage may skip it that would have pinned if they weren't adding almost 1 kB to every response. That's the case I'm worried about. > If we had to solve this one way or the other, I'd prefer to do pinning > CA names, because I think it solves a bigger useability problem for > sites. Maybe I've missed this, but where is the mapping of CA names to keys defined? > > * We could also relax the requirement to send the PKP header on each > > response. To be honest I can't recall now why we required it, but it > > seems like it resolved some security concern? Maybe it's in the > > archives... > I'd strongly advocate for dropping this requirement, though I don't remember the argument for it either. As I've said, in my experience scanning HSTS headers it's rare to see them deployed 100% of the time. Here's an alternative approach I was thinking about which could fix any header-bloat concerns without naming CAs or switching to a well-known URI: add either a "policy-serial-number" directive to the HPKP response header, or have clients compute a hash of each policy they store (definitely doesn't need collision resistance and might not even need to be a crypto hash, not sure if there are attacks if it's just a CRC). If user agents have a cached policy for a site, they send a request header "known-hpkp-policy: " request header with the serial number or policy of the currently known policy. If the server sees this, it can respond with an abbreviated header of just "Public-Key-Pins: extend" which tells the user agent to re-up the current policy. That's it. They can always send a clear message or a new policy if they want. But in the case where header bloat may be a concern because you're doing hundreds of requests to a domain quickly, you can do it all in just a few bits... This adds moderate complexity to the spec and implementation, but probably much less than switching to a well-known URI. --bcaec5014df7cfe05004e311d473 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 1, 2013 at 8:51 PM, Trevor Perrin <trevp@trevp.net> wrote:
On Thu, Aug 1, 2013 at 9:24 AM, Chris Palmer <palmer@google.com> wrote:
> * Regarding generic security policy URI: If we can't achieve conse= nsus
> in this WG, why would adding dependencies on more WGs and W3C help? > Obviously, it would not. Thus, we should stick to defining only
> pinning policy in this draft.

Definitely.

I agree it wouldn't m= ake sense to bog-down the HPKP spec with HSTS (and definitely not CSP). I t= hink the question is, for the next HTTPS policy that sites may want to decl= are, can we make it as easy to do so as possible?=C2=A0

CT is the right test case here because IMO it will be v= ery useful to set a CT-required bit. If refactoring the HPKP spec to a well= -known URI enables CT to push this through in a few months instead of a yea= r, that's a nice benefit though still not the main motivation for switc= hing to a well-known URI.
=C2=A0
They may be an outlier, but= we don't really know. =C2=A0Sites might want
very safe pins that list several CAs, so they have backup options.
And apparently some CAs have several keys (11 for Verisign? =C2=A07 for
GeoTrust?)

Another way of looking at th= is is, how can the spec be written to minimally disincentivize sites from a= dopting it? If sites want to pin but feel they can't deploy a pinning = =C2=A0policy with less than Twitter's 19 hashes, and they have to add t= hat to every response, some percentage may skip it that would have pinned i= f they weren't adding almost 1 kB to every response. That's the cas= e I'm worried about.
=C2=A0
If we had to solve this one way or the other, I'd prefer to do pinning<= br> CA names, because I think it solves a bigger useability problem for
sites.

Maybe I've missed this, but wher= e is the mapping of CA names to keys defined?
=C2=A0
> * We could also relax the requirement to send the PKP header on each > response. To be honest I can't recall now why we required it, but = it
> seems like it resolved some security concern? Maybe it's in the > archives...

I'd strongly= advocate for dropping this requirement, though I don't remember the ar= gument for it either. As I've said, in my experience scanning HSTS head= ers it's rare to see them deployed 100% of the time.

Here's an alternative approach I was thinking about= which could fix any header-bloat concerns without naming CAs or switching = to a well-known URI: add either a "policy-serial-number" directiv= e to the HPKP response header, or have clients compute a hash of each polic= y they store (definitely doesn't need collision resistance and might no= t even need to be a crypto hash, not sure if there are attacks if it's = just a CRC). If user agents have a cached policy for a site, they send a re= quest header "known-hpkp-policy: " request header with the serial= number or policy of the currently known policy.

If the server sees this, it can respond with an abbrevi= ated header of just "Public-Key-Pins: extend" which tells the use= r agent to re-up the current policy. That's it. They can always send a = clear message or a new policy if they want. But in the case where header bl= oat may be a concern because you're doing hundreds of requests to a dom= ain quickly, you can do it all in just a few bits...

This adds moderate complexity to the spec and implement= ation, but probably much less than switching to a well-known URI.
--bcaec5014df7cfe05004e311d473-- From ynir@checkpoint.com Mon Aug 5 03:38:06 2013 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 0FFED21F9E3B for ; Mon, 5 Aug 2013 03:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.503 X-Spam-Level: X-Spam-Status: No, score=-10.503 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6Dn8z6T-ZkW for ; Mon, 5 Aug 2013 03:37:59 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A84E521F9E3A for ; Mon, 5 Aug 2013 03:37:57 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r75Abuwo020358 for ; Mon, 5 Aug 2013 13:37:56 +0300 X-CheckPoint: {51FF8083-4A-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Mon, 5 Aug 2013 13:37:55 +0300 From: Yoav Nir To: IETF WebSec WG Thread-Topic: [websec] #60: Well Known URIs vs Response Headers Thread-Index: AQHOjJuYwSHLWJ6FxEGQqE9b5vLwWJl77USAgAD8uoCAAiUAAIAAx7yAgAAImACAAAPjgIAAeIGAgACNhwCAAu1zgIACbX6A Date: Mon, 5 Aug 2013 10:37:55 +0000 Message-ID: <0C788DC3-4C7F-47D4-B0A6-54E94FC5EAD0@checkpoint.com> References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> <51FA1C35.1090005@mozilla.org> <4B4A645A-793F-4276-96BF-FBA5BA740632@checkpoint.com> <51FA26AD.2020405@gondrom.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.1] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11b5a6e7e1a9f40ac2763d0fa589ef00310353fd8d Content-Type: multipart/alternative; boundary="_000_0C788DC34C7F47D4B0A654E94FC5EAD0checkpointcom_" MIME-Version: 1.0 Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 05 Aug 2013 10:38:06 -0000 --_000_0C788DC34C7F47D4B0A654E94FC5EAD0checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Let me try to summarize where we are with this discussion. There has been some suggestions that all policy headers such as CSP. Howeve= r, a well-known URI is unique per domain, while CSP can be different for ea= ch resource. So only policy elements that are domain-specific rather than r= esource-specific can be in the proposed well-known URI. That list is rather= short: HPKP and HSTS. For now, we can ignore HSTS. If we take the well-kno= wn-uri path and someone later wants to move HSTS to the same or a different= WK URI, that will be a separate effort. With that in mind, the advantages of well-known URIs are obvious: * Less bandwidth than repeating the HTTP header on each response. * No need to send this data to clients that don't support HPKP So the opinions against this that we've heard so far, I will try to summari= ze. I apologize in advance if I over-simplify or misrepresent your position= : * This should not be done as a one-off for HPKP. If it should be done a= t all, it should be done as part of a unified framework for policies (Jeff = Hodges) * "Agree with Jeff" (Chris Palmer, me, a few others) * Current HPKP header is inefficient and inelegant, because there is no= limit on number of hashes, and client needs to validate and update pins on= every resource. (Trevor Perrin) * HSTS deployment does not have the header on every path and every subd= omain. If HPKP is deployed like that, we will have random results. Should u= se WK URI (Joseph Bonneau) * [changing to WK URI] is a good idea, and if we don't do it now, we'll= never do it (Mark Nottingham, Larry Manister) * [changing to WK URI] is a good idea, because HTTP headers are suppose= d to be about the resource, not the site. (Daniel Kahn Gillmor) * Maybe we should finish HPKP as it is, and later start a generic draft= on moving everything to a well-known URI? (Tobias) * We considered this for CSP, and decided against well-known URIs. It's= an extra HTTP request. May have performance implications, and it's no big = deal to have this in every response, since the size is "smallish". In some = network conditions, we might never get to fetch the WK URI, because the "ne= xt conneciton" might come first (Gervase Markham, Mozilla) As chair, I see that there is a majority for making the change, but I did n= ot see the concerns raised by Gervase addressed. It is also troubling that = the people who work on a browser (Chris and Gervase) are both against the c= hange, so I think it's too early to declare consensus, until this issue has= been more thoroughly discussed. Yoav --_000_0C788DC34C7F47D4B0A654E94FC5EAD0checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi

Let me try to summarize where we are with this discussion.

There has been some suggestions that all policy headers such as CSP. H= owever, a well-known URI is unique per domain, while CSP can be different f= or each resource. So only policy elements that are domain-specific rather t= han resource-specific can be in the proposed well-known URI. That list is rather short: HPKP and HSTS. For= now, we can ignore HSTS. If we take the well-known-uri path and someone la= ter wants to move HSTS to the same or a different WK URI, that will be a se= parate effort.

With that in mind, the advantages of well-known URIs are obvious:
  • Less bandwidth than repeating the HTTP header on each response.
    • No need to send this data to clients that don't support HPKP

So the opinions against this that we've heard so far, I will try to su= mmarize. I apologize in advance if I over-simplify or misrepresent your pos= ition:
  • This should not be done as a one-off for HPKP. If it should be done at = all, it should be done as part of a unified framework for policies (Jeff Ho= dges)
  • "Agree with Jeff" (Chris Palmer, me, a few others)<= /li>
  • Current HPKP header is inefficient and inelegant, because there is = no limit on number of hashes, and client needs to validate and update pins = on every resource. (Trevor Perrin)
  • HSTS deployment does not have th= e header on every path and every subdomain. If HPKP is deployed like that, = we will have random results. Should use WK URI (Joseph Bonneau)
  • [ch= anging to WK URI] is a good idea, and if we don't do it now, we'll never do= it (Mark Nottingham, Larry Manister)
  • [changing to WK URI] is = a good idea, because HTTP headers are supposed to be about the resource, no= t the site. (Daniel Kahn Gillmor)
  • Maybe we should finish HPKP as it= is, and later start a generic draft on moving everything to a well-known U= RI? (Tobias)
  • We considered this for CSP, and decided against well-k= nown URIs. It's an extra HTTP request. May have performance implications, a= nd it's no big deal to have this in every response, since the size is "= ;smallish". In some network conditions, we might never get to fetch the WK URI, because the "next conneciton" might com= e first (Gervase Markham, Mozilla)

As chair, I see that there is a majority for making the change, but I = did not see the concerns raised by Gervase addressed. It is also troubling = that the people who work on a browser (Chris and Gervase) are both against = the change, so I think it's too early to declare consensus, until this issue has been more thoroughly disc= ussed.

Yoav

--_000_0C788DC34C7F47D4B0A654E94FC5EAD0checkpointcom_-- From trevp@trevp.net Tue Aug 6 01:51:24 2013 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 18BEA21F918C for ; Tue, 6 Aug 2013 01:51:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utz4UQ8kqkrM for ; Tue, 6 Aug 2013 01:51:18 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id B732B21F9D8B for ; Tue, 6 Aug 2013 01:51:12 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id a12so103515wgh.18 for ; Tue, 06 Aug 2013 01:51:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mju0dQNwoYom5p4lmp/bkZfJnrJsxW40XbKUG8r/jVY=; b=NUPZUdTwQCcVJDsTsDF3pp97t8egnYYGSYaDeNJ5Ihz7lILhm9dq66LbO9lGQWEUIt yUwLqlMWcDFEFBctKOvK0C620vsaVMK7ejzsILofxvHMfy1UxUjVPvp33AR/5QC1C+ef PMxfQNItbZIDmXFYuzBwS2s/5meMgpr6QCKMdZSd77wzQ5UCMIaKAF0I+OujtKkd89P+ AdAzXZX011Q4h9ApsvcaWCzTqS5GgCaiAJhUxhAhhzGtW2MP74OvEfW/18MiZTJaykPl eflrR2OlNIjj0yp3xcvMmw3QmmxIZTWoWUWuc6lCKnWBZVBXWUxZwH3Z6zHNqlG1c7Uo 17xA== X-Gm-Message-State: ALoCoQlP4dF4V0PUbWH0H9TRz7+CO26sxOL8PYjPv+jNc5Ty/u78lGy1pM7kYOOjxqINy/GBE312 MIME-Version: 1.0 X-Received: by 10.180.103.194 with SMTP id fy2mr1195752wib.17.1375779071645; Tue, 06 Aug 2013 01:51:11 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Tue, 6 Aug 2013 01:51:11 -0700 (PDT) X-Originating-IP: [166.137.180.4] In-Reply-To: <0C788DC3-4C7F-47D4-B0A6-54E94FC5EAD0@checkpoint.com> References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> <51FA1C35.1090005@mozilla.org> <4B4A645A-793F-4276-96BF-FBA5BA740632@checkpoint.com> <51FA26AD.2020405@gondrom.org> <0C788DC3-4C7F-47D4-B0A6-54E94FC5EAD0@checkpoint.com> Date: Tue, 6 Aug 2013 01:51:11 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 06 Aug 2013 08:51:24 -0000 On Mon, Aug 5, 2013 at 3:37 AM, Yoav Nir wrote: > > Let me try to summarize where we are with this discussion. Good summary. Here's more complications... * It would be good if crawlers and "network notaries" could reliably query the HPKP for a site. Sending an HPKP header on every response accomplishes this. So does a .well-known URI. But letting the server return the header whenever/wherever it feels like does not. (Joe suggested having servers send the HPKP header only in response to a request header. While that may help with header bloat, it doesn't solve this problem, because (as Joe points out) many sites don't return HSTS consistently across URIs. This is probably due to different backend webservers being configured differently. These servers wouldn't consistently respond to a request header either.) * I argued that .well-known URI lookup could be async to page-load, thus wouldn't add page-load latency. Gerv countered that there may be "timing issues" - in particular, such an async lookup might not complete before the "next connection". I'm not sure what counts as the "next connection", and I'm not sure we need such a strict ordering requirement. But one timing issue, I think, is that async lookup means a separate TLS connection. And that means that a network MITM, even without a certificate, could filter out the .well-known lookups without affecting the rest of the page load, thus preventing clients from forming pins. Not sure if there's a good way to deal with this. -- I wonder if HPKP should go in both a Response header *and* a well-known URI? By allowing it in the response header, we can prevent a MITM from filtering out the HPKP data. But we don't need to require it on all responses, because there may be inconsistently configured servers. And CA pins would still be a good idea to reduce header size (and improve useability). Putting HPKP data in a well-known URI gives clients a reliable way to query for HPKP. Anyone like this? Trevor From trevp@trevp.net Tue Aug 6 13:02:36 2013 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 15AA121E809E for ; Tue, 6 Aug 2013 13:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwkxpWCL3Xg0 for ; Tue, 6 Aug 2013 13:02:31 -0700 (PDT) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by ietfa.amsl.com (Postfix) with ESMTP id 28D1021E809B for ; Tue, 6 Aug 2013 13:02:30 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so768282wes.40 for ; Tue, 06 Aug 2013 13:02:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Q6hM3juKKwvsM7G39ErniIs3BZS4Blc4hTYMDFZq7jg=; b=cGmw0HWZsoHhmU4KtabsmP/Ml7qP5j86nlkDSMa5azU7yAkORzXVBvpPNgGmBHM5pJ iYPuhf5Tgbr0MT0gfotkO0rQFRrF5CyZhidbEbIO+1CsoPjC7yv1wWxRx3U/mZo4hq6Y zHgz6bEhi86E7yrEn4KRdM3riax0f5Dltv/bR/wF6834NlcrMUqIpudu7ePvObrLgoX7 QZj3dAOvVSFI0fCGkPibOqx4eSc0tIJtSOFDLUsol5oY9lAt+NasXUYDAXsOA3nwhsEX sWHen1+qieEjjZQuyytrxMkN5Pv7rMXwVtQ9Q/eJtiffKTu+zDVPb9L6GvazZet0ig45 ylMg== X-Gm-Message-State: ALoCoQlh6klRJjR8ndhXpaC/Tpldj2tZbn+vY1vwAWFsVbOK9OQAiNsDcaTU44V8K3S/qvtD/fm2 MIME-Version: 1.0 X-Received: by 10.194.249.165 with SMTP id yv5mr2414394wjc.9.1375819349796; Tue, 06 Aug 2013 13:02:29 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Tue, 6 Aug 2013 13:02:29 -0700 (PDT) X-Originating-IP: [204.62.111.55] In-Reply-To: References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> <51FA1C35.1090005@mozilla.org> <4B4A645A-793F-4276-96BF-FBA5BA740632@checkpoint.com> <51FA26AD.2020405@gondrom.org> <0C788DC3-4C7F-47D4-B0A6-54E94FC5EAD0@checkpoint.com> Date: Tue, 6 Aug 2013 13:02:29 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 06 Aug 2013 20:02:36 -0000 On Tue, Aug 6, 2013 at 1:51 AM, Trevor Perrin wrote: > On Mon, Aug 5, 2013 at 3:37 AM, Yoav Nir wrote: > > I wonder if HPKP should go in both a Response header *and* a well-known URI? Another alternative is to return HPKP as a TLS ServerHello Extension, sent when the client requests it (same as TACK or Certificate Transparency). Pros: * Webcrawlers etc. can reliably retrieve the pinning policy. * The data is only presented during TLS handshakes, so clients aren't being asked to process HPKP and update their local store constantly. * Sites commonly terminate TLS at a pool of similar hosts, then forward connections to various back-end webservers. So the TLS terminators are a choke-point where it's easier to publish security policy consistently, as opposed to trying to keep all back-end webservers in sync. * The pinning data can be used with other protocols (e.g. email). Cons: * Pushing changes into OpenSSL, NSS, and other TLS stacks is difficult. However OpenSSL head now supports "serverinfo" extensions that are PEM-encoded blobs contained in a config file, and returned in response to client requests. This is sufficient for CT and TACK, and could work for HPKP. NSS could be extended to allow clients to register "custom extension" handlers. Were all this to happen, it would be possible to deploy simple new TLS extensions without OpenSSL, NSS, or Apache changes. * The ServerHello is sent early in the TCP Connection, before the initcwnd window has widened. So space is at a premium, since exceeding the typical 4KB size for ServerHello incurs a RT of latency. Thus it would be even more important to reduce HPKP size via named CA pins. But I think this is important anyways, for usability. * There are some TLS-intolerant firewalls which trigger some (but not all) browsers to fallback to SSLv3 [1]. SSLv3 doesn't support TLS extensions. This causes a range of security problems. I'm hopeful we can get more browsers to take a hard line against this and drive these boxes to be upgraded, so workarounds like "special ciphersuite values" aren't necessary. In any case, this problem affects a wide range of TLS enhancements, so there's general interest in fixing it. Trevor [1] http://www.ietf.org/mail-archive/web/tls/current/msg09450.html From ryan-ietfhasmat@sleevi.com Tue Aug 6 14:51:48 2013 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 366FA21F99C2 for ; Tue, 6 Aug 2013 14:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uknXrt5WYsv for ; Tue, 6 Aug 2013 14:51:43 -0700 (PDT) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by ietfa.amsl.com (Postfix) with ESMTP id 4337B21F99A2 for ; Tue, 6 Aug 2013 14:51:43 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by hapkido.dreamhost.com (Postfix) with ESMTP id 827641872B for ; Tue, 6 Aug 2013 14:51:42 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 9C159B805B; Tue, 6 Aug 2013 14:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=5CtxIyoqU/i1u1n1v6bZckJXPhU=; b=KzAFISYd/wrAh5OLs noyJ17eBqMhFWA2uZ/gVnfMWRMmNYZk4gZLItPgt0Kg7WPrwB0X4CMt/Xsp1v6K8 ZOc7mn6R3Tqc/EiqrfzQYz8ZtcYKJwbSsSrZDML4MTURVHIDAjWLIo7zkX5rktth AZy7wT68vyBhPZcNbddxsfhnlo= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPA id 09BBBB806D; Tue, 6 Aug 2013 14:51:39 -0700 (PDT) Received: from 216.239.45.93 (proxying for 216.239.45.93) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Tue, 6 Aug 2013 14:51:41 -0700 Message-ID: In-Reply-To: References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> <51FA1C35.1090005@mozilla.org> <4B4A645A-793F-4276-96BF-FBA5BA740632@checkpoint.com> <51FA26AD.2020405@gondrom.org> <0C788DC3-4C7F-47D4-B0A6-54E94FC5EAD0@checkpoint.com> Date: Tue, 6 Aug 2013 14:51:41 -0700 From: "Ryan Sleevi" To: "Trevor Perrin" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:51:48 -0000 On Tue, August 6, 2013 1:02 pm, Trevor Perrin wrote: > On Tue, Aug 6, 2013 at 1:51 AM, Trevor Perrin wrote: > > On Mon, Aug 5, 2013 at 3:37 AM, Yoav Nir wrote: > > > > I wonder if HPKP should go in both a Response header *and* a well-kno= wn > > URI? > > > Another alternative is to return HPKP as a TLS ServerHello Extension, > sent when the client requests it (same as TACK or Certificate > Transparency). While appealing from a 'spec purity' point, I think the idea of using it as a ServerHello extension is a concept that's more or less DOA, in that it still leaves an unfortunate gap of servers that will not be able to do anything to allow clients to discover this policy. I think the cons for it definitely outweigh the pros. Even though there i= s general interest in fixing the negotiation problem, it'd be a real shame to lose an extremely valuable security policy by forcing it to go down a path we know doesn't universally work. Further, I think it vastly underestimates the work required to get it practically adopted - even if two widely-used SSL stacks are easily amenable to it, you completely miss out for platforms such as iOS, Android, OS X, or Windows, short of platform upgrades, which we know are less than frequent. Having a well-known URI *without* a Response header is an idea I'd like t= o suggest is also DOA, simply because it creates yet-another-throwaway request for the vast majority of sites (which we can reasonably presume *won't* be pinned). IF a well-known URI was adopted, minimally there should also be a Respons= e header to signal the existence of a well-known URI, so that you aren't forcing an additional request for a non-existent file on every request (see the favicon.ico debacle). As Gerv mentioned, the practicality of the well-known URI is suspect. While it's "easy" to think of browsers as simply starting one connection, making a fetch, and then opening additional connections as needed, "up to 2", the reality is far, far divorced from that in just about "Every Moder= n Browser". It's not uncommon for additional connections to be opened based on previously observed data - whether it be things like "DNS preloading" or speculative fetches for resources commonly observed as related. The benefit of the current, header-based approach is that immediately upon processing the headers of the first request, all other requests can be evaluated against that policy - before even the remainder of the body request is retrieved. In a WK-URI world, the policy cannot be applied until a request for the additional URL is made (which may require additional connections to be made or interrupting/aborting these speculative connections). In an HTTP/2.0 world, where 'everything' is multiplexed over a single logical connection, I would heartily agree that this is less of a concern= . But in an HTTP/1.0 and HTTP/1.1 world - which will still be here for a while - it's a very real concern. For those not familiar with these concerns from the browser/user-agent perspective, at the risk of promotion I'd suggest checking out my colleague Ilya Grigorik's (presently available free) book "High Performance Browser Networking" ( http://chimera.labs.oreilly.com/books/1230000000545 ), in particular the lessons learned, user metrics gained, and graphs discussed in chapters 9-13. That's not to say that Well-Known URIs are not extremely tempting, for some of the reasons already expressed by Joe and Trevor, but I think it may be missed some of the downsides that are not necessarily present in the current header-based approach. In our mind, one of the biggest factors has been "What are the hurdles to practical deployment?". While there is admittedly complexity from the header approach, it's our view that it's not greater than the inherent complexity of effective pinning, as enumerated in the existing considerations. The complexity of an efficient and reasonable implementation of well-known URIs, or of a practical deployment of server extensions, seems to greatly outweigh both, and the benefits are not as seemingly significant. Cheers, Ryan > > Pros: > > * Webcrawlers etc. can reliably retrieve the pinning policy. > > * The data is only presented during TLS handshakes, so clients aren't > being asked to process HPKP and update their local store constantly. > > * Sites commonly terminate TLS at a pool of similar hosts, then > forward connections to various back-end webservers. So the TLS > terminators are a choke-point where it's easier to publish security > policy consistently, as opposed to trying to keep all back-end > webservers in sync. > > * The pinning data can be used with other protocols (e.g. email). > > > Cons: > > * Pushing changes into OpenSSL, NSS, and other TLS stacks is > difficult. However OpenSSL head now supports "serverinfo" extensions > that are PEM-encoded blobs contained in a config file, and returned in > response to client requests. This is sufficient for CT and TACK, and > could work for HPKP. NSS could be extended to allow clients to > register "custom extension" handlers. Were all this to happen, it > would be possible to deploy simple new TLS extensions without OpenSSL, > NSS, or Apache changes. > > * The ServerHello is sent early in the TCP Connection, before the > initcwnd window has widened. So space is at a premium, since > exceeding the typical 4KB size for ServerHello incurs a RT of latency. > Thus it would be even more important to reduce HPKP size via named CA > pins. But I think this is important anyways, for usability. > > * There are some TLS-intolerant firewalls which trigger some (but not > all) browsers to fallback to SSLv3 [1]. SSLv3 doesn't support TLS > extensions. This causes a range of security problems. I'm hopeful we > can get more browsers to take a hard line against this and drive these > boxes to be upgraded, so workarounds like "special ciphersuite values" > aren't necessary. In any case, this problem affects a wide range of > TLS enhancements, so there's general interest in fixing it. > > > Trevor > > [1] http://www.ietf.org/mail-archive/web/tls/current/msg09450.html > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From jbonneau@gmail.com Tue Aug 6 15:15:28 2013 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 5A63821F9EB0 for ; Tue, 6 Aug 2013 15:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEq3IYtHl3la for ; Tue, 6 Aug 2013 15:15:27 -0700 (PDT) Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9847A21F9EC4 for ; Tue, 6 Aug 2013 15:15:27 -0700 (PDT) Received: by mail-vb0-f54.google.com with SMTP id q14so1064394vbe.41 for ; Tue, 06 Aug 2013 15:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+Ok0x27MeUcJMlO+q+BN1Mj0DvnLq97wiSYMQiQ5P1k=; b=jMXVflcldR7INQJmnlUto7hZ8I5ZAGIoGT+9sUqymM2yh3mekU3Vj/fnZARk6EF5l0 XlcTzmJ88jFoXGi7s/QgStkvyCy6njGdw8QuWiTYhnl5+tu+rm84MaAVUjcvps6ktrze wd/s5e9OzaB4qloHl0I/FIr0M9/1Ud+9kIj14c/yy6VZwa+Tk2QHk69n3zXBcSsuk8AY 0HdNx2v9zAD2ERHES03jJxB/b7J5bH6WSrgTKkRFIDTMX/Rt3pQgR3pMWzTAIwNj4Gso 7CMa/B+fVuDIpC0ErTNxB8Z/1D8hfaplRGpd0a3UAhhIK0XptrLit1i+nri4Z6Y3JlsR HOFg== X-Received: by 10.58.219.232 with SMTP id pr8mr72062vec.80.1375827327009; Tue, 06 Aug 2013 15:15:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.62.73 with HTTP; Tue, 6 Aug 2013 15:15:06 -0700 (PDT) In-Reply-To: References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> <51FA1C35.1090005@mozilla.org> <4B4A645A-793F-4276-96BF-FBA5BA740632@checkpoint.com> <51FA26AD.2020405@gondrom.org> <0C788DC3-4C7F-47D4-B0A6-54E94FC5EAD0@checkpoint.com> From: Joseph Bonneau Date: Tue, 6 Aug 2013 18:15:06 -0400 Message-ID: To: ryan-ietfhasmat@sleevi.com Content-Type: multipart/alternative; boundary=047d7bd6b88c194a6f04e34ec351 Cc: IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 06 Aug 2013 22:15:28 -0000 --047d7bd6b88c194a6f04e34ec351 Content-Type: text/plain; charset=UTF-8 > In our mind, one of the biggest factors has been "What are the hurdles to > practical deployment?". While there is admittedly complexity from the > header approach, it's our view that it's not greater than the inherent > complexity of effective pinning, as enumerated in the existing > considerations. The complexity of an efficient and reasonable > implementation of well-known URIs, or of a practical deployment of server > extensions, seems to greatly outweigh both, and the benefits are not as > seemingly significant. I am in agreement that a TLS extension seems like far too much to ask of deploying sites. I'm also appreciating more and more from this thread the difficulty of a well-known URI and though I think it's a cleaner approach in the long-term I can see the argument that it's too much to do right now. I'm fully on-board with headers if we can address two issues that I think are real impediments to servers deploying HPKP and doing so correctly: (a) header bloat (600 bytes of for a site requiring 10 pins) (b) inadvertent HPKP hole-punching when resources are accidentally served without headers set. Other issues (e.g. discoverability by crawlers) seem secondary. I think we can address (b) by not interpreting a missing HPKP header as a max-age=0, and I was hoping we could deal with (a) by clients sending a hash or policy serial number to avoid repeatedly sending the header. Does this approach add too much complexity given the level of concern about header bloat, which doesn't seem huge? --047d7bd6b88c194a6f04e34ec351 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In our mind, one of the biggest factors has been "What are the hurdles= to
practical deployment?". While there is admittedly complexity from the<= br> header approach, it's our view that it's not greater than the inher= ent
complexity of effective pinning, as enumerated in the existing
considerations. The complexity of an efficient and reasonable
implementation of well-known URIs, or of a practical deployment of server extensions, seems to greatly outweigh both, and the benefits are not as
seemingly significant.

I am in agreement th= at a TLS extension seems like far too much to ask of deploying sites. I'= ;m also appreciating more and more from this thread the difficulty of a wel= l-known URI and though I think it's a cleaner approach in the long-term= I can see the argument that it's too much to do right now.

I'm fully on-board with headers if we can address t= wo issues that I think are real impediments to servers deploying HPKP and d= oing so correctly: (a) header bloat (600 bytes of=C2=A0for a site requiring= 10 pins) (b) inadvertent HPKP hole-punching when resources are accidentall= y served without headers set. Other issues (e.g. discoverability by crawler= s) seem secondary.

I think we can address (b) by not interpreting a missin= g HPKP header as a max-age=3D0, and I was hoping we could deal with (a) by = clients sending a hash or policy serial number to avoid repeatedly sending = the header. Does this approach add too much complexity given the level of c= oncern about header bloat, which doesn't seem huge?
--047d7bd6b88c194a6f04e34ec351-- From ynir@checkpoint.com Tue Aug 6 23:20:11 2013 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 CF82921F8FDC for ; Tue, 6 Aug 2013 23:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.508 X-Spam-Level: X-Spam-Status: No, score=-10.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA-1TphoFcI4 for ; Tue, 6 Aug 2013 23:20:03 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C0B6121F8F4F for ; Tue, 6 Aug 2013 23:20:02 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r776K1Mj028409 for ; Wed, 7 Aug 2013 09:20:01 +0300 X-CheckPoint: {5201E711-1-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Wed, 7 Aug 2013 09:20:00 +0300 From: Yoav Nir To: websec Thread-Topic: [websec] #58: Should we pin only SPKI, or also names Thread-Index: AQHOjHagv3/BmvZ4wU6WrbkIw+Bd/ZmAXZOAgAADk4CAAHu6gIAIRDGA Date: Wed, 7 Aug 2013 06:19:59 +0000 Message-ID: <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> In-Reply-To: <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.54] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 1148d0e074cc7892dfa87de41a27e368dc1bbcbb49 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <40F97ACD5C56864F9C2B54ABB8A83F2E@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 07 Aug 2013 06:20:11 -0000 [with chair hat on] Hi So far, only Phil and Jeremy have been in favor of making this change. I do= n't think we have consensus for this change. Even if others chime in now and say that they do want this change, I think = we can't just ask administrators to list random names in headers or resourc= es. For example, what string do you use for the bunch of trust anchors form= erly known as "Verisign"? Do you call it "Verisign"? "VERISIGN"? "Symante= c"? Are the Thawte public keys covered by the "Symantec" label? the "Verisi= gn" label? A wrong choice by an administrator (like getting your next cert= ificate from a Thawte brand CA and expecting it to be covered by your "Syma= ntec" pin) could lead to bricking the site. That is not to say we must not do this, but we must not do this without a r= egistry for CA strings. The go to body for registries at the IETF is IANA, = but I don't think we've ever had an IANA registry for brand names. So unles= s we can get some body (the CA/Browser Forum ?) to create such a registry a= nd provide a stable link that we can reference, I think this is a non-start= er. Even with such a registry, I don't see consensus for this. Yoav From ynir@checkpoint.com Tue Aug 6 23:28:32 2013 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 483F021E8050 for ; Tue, 6 Aug 2013 23:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.509 X-Spam-Level: X-Spam-Status: No, score=-10.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clNhQdEHLwJ1 for ; Tue, 6 Aug 2013 23:28:27 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id CD8BE21E8051 for ; Tue, 6 Aug 2013 23:28:26 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r776SO7i032044; Wed, 7 Aug 2013 09:28:24 +0300 X-CheckPoint: {5201E908-17-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Wed, 7 Aug 2013 09:28:23 +0300 From: Yoav Nir To: "" Thread-Topic: [websec] #60: Well Known URIs vs Response Headers Thread-Index: AQHOjJuYwSHLWJ6FxEGQqE9b5vLwWJl77USAgAD8uoCAAiUAAIAAx7yAgAAImACAAAPjgIAAeIGAgACNhwCAAu1zgIACbX6AgAF0g4CAALuPgIAAHoKAgACQWgA= Date: Wed, 7 Aug 2013 06:28:22 +0000 Message-ID: <282DF116-E908-4C7E-8387-A7E69E1C0848@checkpoint.com> References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> <51FA1C35.1090005@mozilla.org> <4B4A645A-793F-4276-96BF-FBA5BA740632@checkpoint.com> <51FA26AD.2020405@gondrom.org> <0C788DC3-4C7F-47D4-B0A6-54E94FC5EAD0@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.54] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 116a3526a41b602533b32dc5ec520a0df22a32457c Content-Type: text/plain; charset="iso-8859-1" Content-ID: <419D1575F0C5E64E872FE97CFAE1A7AA@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 07 Aug 2013 06:28:32 -0000 [no hats] On Aug 7, 2013, at 12:51 AM, Ryan Sleevi wrote= : >=20 >=20 > In an HTTP/2.0 world, where 'everything' is multiplexed over a single > logical connection, I would heartily agree that this is less of a concern= . > But in an HTTP/1.0 and HTTP/1.1 world - which will still be here for a > while - it's a very real concern. Both ideas get better with HTTP/2.0. the WK URI can be always requested wit= h lowest priority, so it doesn't interfere with loading the web page. And h= eader bloat does not matter that much if the header is included only once p= er TCP connection. > For those not familiar with these concerns from the browser/user-agent > perspective, at the risk of promotion I'd suggest checking out my > colleague Ilya Grigorik's (presently available free) book "High > Performance Browser Networking" ( > http://chimera.labs.oreilly.com/books/1230000000545 ), in particular the > lessons learned, user metrics gained, and graphs discussed in chapters > 9-13. >=20 > That's not to say that Well-Known URIs are not extremely tempting, for > some of the reasons already expressed by Joe and Trevor, but I think it > may be missed some of the downsides that are not necessarily present in > the current header-based approach. >=20 > In our mind, one of the biggest factors has been "What are the hurdles to > practical deployment?". While there is admittedly complexity from the > header approach, it's our view that it's not greater than the inherent > complexity of effective pinning, as enumerated in the existing > considerations. The complexity of an efficient and reasonable > implementation of well-known URIs, or of a practical deployment of server > extensions, seems to greatly outweigh both, and the benefits are not as > seemingly significant. +1 Yoav From gerv@mozilla.org Wed Aug 7 01:03:17 2013 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 CF8EA21E8083 for ; Wed, 7 Aug 2013 01:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmTNn-bEQ9Af for ; Wed, 7 Aug 2013 01:03:12 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id E4F4D21E80DA for ; Wed, 7 Aug 2013 01:03:11 -0700 (PDT) Received: from [192.168.0.22] (cpc2-enfi16-2-0-cust610.hari.cable.virginmedia.com [94.170.82.99]) (Authenticated sender: gerv@mozilla.org) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 3783AF211B; Wed, 7 Aug 2013 01:03:09 -0700 (PDT) Message-ID: <5201FF3C.3060804@mozilla.org> Date: Wed, 07 Aug 2013 09:03:08 +0100 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yoav Nir References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> In-Reply-To: <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 07 Aug 2013 08:03:18 -0000 On 07/08/13 07:19, Yoav Nir wrote: > Even if others chime in now and say that they do want this change, I > think we can't just ask administrators to list random names in > headers or resources. For example, what string do you use for the > bunch of trust anchors formerly known as "Verisign"? Do you call it > "Verisign"? "VERISIGN"? "Symantec"? Are the Thawte public keys > covered by the "Symantec" label? the "Verisign" label? A wrong > choice by an administrator (like getting your next certificate from a > Thawte brand CA and expecting it to be covered by your "Symantec" > pin) could lead to bricking the site. Without expressing an opinion on the question, it's worth noting that this is already an issue with CAA, albeit that Symantec has to decide a set of domain names (rather than simple strings) to represent them or their brands. This was not a particularly difficult exercise for them, they probably have the most roots and most brands, and it only had to be done once. So I'd suggest that it's not an insuperable obstacle. > That is not to say we must not do this, but we must not do this > without a registry for CA strings. Or just require people to use "a domain name I control" rather than a bare string, like CAA. No need for a registry. Gerv From trevp@trevp.net Wed Aug 7 02:28:45 2013 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 66B8811E8103 for ; Wed, 7 Aug 2013 02:28:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTnHfXRd9gN7 for ; Wed, 7 Aug 2013 02:28:40 -0700 (PDT) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by ietfa.amsl.com (Postfix) with ESMTP id DF31E11E80E6 for ; Wed, 7 Aug 2013 02:28:39 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so1277388wes.26 for ; Wed, 07 Aug 2013 02:28:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gesWHJT8FmOPPcydLDGxeKM7xqgj8PBZDUEzCyq4QNQ=; b=aGNiAn6VaI/up2CHG3FmWpVaPXPxk6z2y/TNVEjmTNJptswuO6MoctzbbKVoAmFGoz 7QvCAZ+Y7z5ShMrqYn5gRz7s6REQ6dRt8FSBuRlwlBkOPiWaI8awyBIWq7BFl98uCGKM 4sM5zpG3F9npQq87ZV8X6k4Ab/l6mMLN4/BpFSMvKGCg0YuYYZu++GtgDvQ4913BSIH8 QDUdmtiDycYBDXq9vN7U85mYIrpY7dPI4H+78qoB8rDOyCM5Iz/NXmo8C/5onqgWW1tU ZScIzh7jb44B2jTd6xW/c2V0JLDA/NbzG3b5wk8pYfNKK8+hVzUH5pX/urmZ782NHONP M66A== X-Gm-Message-State: ALoCoQm+Zycsb47/NYpVxnXBvn/rMK4d/AqeCm5ghvhhgvGKwABk6sFwiyEXhf5t22NWKsvKcIb7 MIME-Version: 1.0 X-Received: by 10.194.190.201 with SMTP id gs9mr1632792wjc.82.1375867718848; Wed, 07 Aug 2013 02:28:38 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Wed, 7 Aug 2013 02:28:38 -0700 (PDT) X-Originating-IP: [24.234.64.225] In-Reply-To: <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> Date: Wed, 7 Aug 2013 02:28:38 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 07 Aug 2013 09:28:45 -0000 On Tue, Aug 6, 2013 at 11:19 PM, Yoav Nir wrote: > > So far, only Phil and Jeremy have been in favor of making this change. I'm in favor. This is relevant to the .well-known URI vs HTTP Header discussion. Pinning CA names would reduce HPKP size, making frequent sending of headers more palatable. More importantly, maintaining a list of key hashes for a set of CAs is a complex undertaking. I think many potential adopters will be scared away, or will do it incorrectly (pinning keys they shouldn't, omitting keys they should, not keeping the list current, and so on). Consider that Google has offered preloaded key pins in Chrome since May 2011 [1]. Since then it looks like ~100 organizations (apart from Google) have signed up for preloaded HSTS. Only 3 have signed up for preloaded key pins. That suggests we need to do more to make pinning attractive. Of those 3, one is a major website with a number of subdomains and some content served over CDN. It's pinning two sets of keys, one with 36 keys, one with 19. The WG seems eager to dismiss this as a zany "outlier" case. I think that's a cavalier attitude towards one of the best data points we have. It's entirely possible that many websites would have to construct lists of similar size and complexity (or worse). -- Finally, let's look into our hearts. Imagine you had to construct an HPKP header that includes a few popular CAs (Symantec, Comodo, and GoDaddy, for instance). You of course want to exclude irrelevant roots (like code-signing). And revoked, expired, or soon-to-be-expired roots. And cryptographically weak roots (e.g. 1024-bit RSA). And you'd need to include enough root or intermediate keys to cover all cert paths all browsers might construct for all certs these businesses might issue to you over the pin timeframe. (Taking into account the vagaries of root ownership, cross-certification, AIA chasing, etc.) And once you've figured that out, you've got to track it over time. Keys could get revoked, expire, change hands, acquire or issue new certificates, and get added or removed from root stores. To me, this sounds difficult even for web PKI experts, and close to unmanageable for anyone who isn't. -- Anyways, I hope HPKP can offer websites a safe and easy route to declaring CA pins. I think that means improving usability. If people think I'm wildly exaggerating the usability issues, or have other proposals / explanations of how to solve them, I'd like to hear that... Trevor [1] https://www.imperialviolet.org/2011/05/04/pinning.html From gerv@mozilla.org Wed Aug 7 02:36:00 2013 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 418E821E80B1 for ; Wed, 7 Aug 2013 02:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtM64egrddU2 for ; Wed, 7 Aug 2013 02:35:54 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 71B5421F99AB for ; Wed, 7 Aug 2013 02:35:54 -0700 (PDT) Received: from [192.168.0.22] (cpc2-enfi16-2-0-cust610.hari.cable.virginmedia.com [94.170.82.99]) (Authenticated sender: gerv@mozilla.org) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 71FF9F213E; Wed, 7 Aug 2013 02:35:52 -0700 (PDT) Message-ID: <520214F7.8020308@mozilla.org> Date: Wed, 07 Aug 2013 10:35:51 +0100 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Trevor Perrin References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 07 Aug 2013 09:36:00 -0000 On 07/08/13 10:28, Trevor Perrin wrote: > This is relevant to the .well-known URI vs HTTP Header discussion. > Pinning CA names would reduce HPKP size, making frequent sending of > headers more palatable. Surely it would also significantly reduce flexibility? At the moment, I can pin to a particular leaf, or a particular intermediate, or a particular root, or to a set of any of the above. I can decide where in the chain to pin depending on my analysis of the cost/benefit. If we instead pinned to CA names, I would lose that flexibility. Wouldn't I? Gerv From trevp@trevp.net Wed Aug 7 02:45:56 2013 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 8B33711E8122 for ; Wed, 7 Aug 2013 02:45:56 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHoF04YwHzNo for ; Wed, 7 Aug 2013 02:45:50 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 00A4611E811E for ; Wed, 7 Aug 2013 02:45:49 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hr7so3652446wib.16 for ; Wed, 07 Aug 2013 02:45:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6K9LeV71/bxgrsJq+K8mpsWSgF/jtW60NJ6pVpYbXBQ=; b=Durjmio3neSBlzQbIuaDLGny2pEHURycwWHjpc6E552AEuTmkZ0211ddjDqKZXHMiR r5cl0hxObCXgTNERKaVgNbUmOJZC17TAZPenqn62hkbroXAHta9r5tTlrjmrlr1D/h41 q5KHCgtnrZqrFwTfyoqF6tHlLCoY1Ihnt7xjE+Po0sZB1xKdlK+fID3cH+VWrECPbxMd Xk9V4Qi2wSuGXgmszrEFu5Sokz2z6iDF+EIdKPjYsxYaeLqQs9S0Tt0v8HJonkxI/TiU 7cQZr8JMpzAoMV3RmVDBIQML8cu/nNG8HTTmSm28qObLoQmjpv3ZxDaDgQIKCgfABbn7 SLeg== X-Gm-Message-State: ALoCoQnPSIqPxaF6N6lypFIZmMcZuacP6FqxazkmkJOV5smGIWE0BgDuVwBCQf/oXggUJNOYdROC MIME-Version: 1.0 X-Received: by 10.194.174.36 with SMTP id bp4mr1738244wjc.7.1375868749032; Wed, 07 Aug 2013 02:45:49 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Wed, 7 Aug 2013 02:45:48 -0700 (PDT) X-Originating-IP: [24.234.64.225] In-Reply-To: <520214F7.8020308@mozilla.org> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520214F7.8020308@mozilla.org> Date: Wed, 7 Aug 2013 02:45:48 -0700 Message-ID: From: Trevor Perrin To: Gervase Markham Content-Type: text/plain; charset=ISO-8859-1 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 07 Aug 2013 09:45:56 -0000 On Wed, Aug 7, 2013 at 2:35 AM, Gervase Markham wrote: > On 07/08/13 10:28, Trevor Perrin wrote: >> This is relevant to the .well-known URI vs HTTP Header discussion. >> Pinning CA names would reduce HPKP size, making frequent sending of >> headers more palatable. > > Surely it would also significantly reduce flexibility? I wouldn't remove key pinning. Just allow pinning to CA names as well. So an HPKP header could list keys both "directly" (by hash value) and "indirectly" (by name). Presumably the browser would have a table mapping names to key lists, and would evaluate a site's cert chain by checking for an intersection with all relevant keys in the pin (direct or indirect). > At the moment, I can pin to a particular leaf, or a particular > intermediate, or a particular root, or to a set of any of the above. I > can decide where in the chain to pin depending on my analysis of the > cost/benefit. I'm not suggesting disallowing that. That sounds a bit complicated for most sites, though. I'm imagining that listing several trustworthy CAs, by name, would be a safer and easier pin for most? Trevor From gerv@mozilla.org Wed Aug 7 02:55:22 2013 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 9D7BB21E80C0 for ; Wed, 7 Aug 2013 02:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jH0nc4wKPu4S for ; Wed, 7 Aug 2013 02:55:16 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id C367321E80A3 for ; Wed, 7 Aug 2013 02:55:16 -0700 (PDT) Received: from [192.168.0.22] (cpc2-enfi16-2-0-cust610.hari.cable.virginmedia.com [94.170.82.99]) (Authenticated sender: gerv@mozilla.org) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id DF47DF222C; Wed, 7 Aug 2013 02:55:15 -0700 (PDT) Message-ID: <52021982.8030108@mozilla.org> Date: Wed, 07 Aug 2013 10:55:14 +0100 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Trevor Perrin References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520214F7.8020308@mozilla.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 07 Aug 2013 09:55:22 -0000 On 07/08/13 10:45, Trevor Perrin wrote: > Presumably the browser would have a table mapping names to key lists, > and would evaluate a site's cert chain by checking for an intersection > with all relevant keys in the pin (direct or indirect). Yes; this would need to be metadata associated with each cert in the root store. It would need to be added when roots were added. What happens if a CA requests a change to this mapping? This might violate the expectations of some users as to which keys they were pinning. Gerv From trevp@trevp.net Wed Aug 7 03:14:18 2013 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 3594921E80C0 for ; Wed, 7 Aug 2013 03:14:18 -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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-IoJXtYUeMt for ; Wed, 7 Aug 2013 03:14:12 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id CD8E921E80BE for ; Wed, 7 Aug 2013 03:14:11 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b13so1333922wgh.19 for ; Wed, 07 Aug 2013 03:14:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/CPrCiLunbss4LvN+JWpj16I1xdwUGlTLQCSptSFaIY=; b=KZpMD2TTC6+i0BidPQTWb9zAUdbj4JAlBmizuCoKUz54ZgzlTxeWxQVkbgsG4jMz9v BPiSIKGk5L1nLP4YzTerOL3YpvQA2tk8t60s3+vWtCdNULwL5g8Ag37hSwCG8eNUIu03 JMXQvxIkTy7GHZsJW63CqCGzVHEsuOK9B831yRBz7OitLv99rsrWlXD8j7OwAOCEqOTf yV+kYpfn9+MJ+dUNvak+XHA4qSXZYtdz7j0vEA4Dipl3YJiK+SGgcBs5GRP8lwPzgOal 0Z/PHQDIdzG7lXefqCWB+q543IBJqNPfAkMRe5/6kzko25BZF3hEapZbvatTLnZ5unid oL6w== X-Gm-Message-State: ALoCoQlFFtN/aT5lp9lm0AX3Pj0NDlqjjleKjP8EbGlPRhDauufLnLDQ2lc6Llgp3gIyX2WpZkdV MIME-Version: 1.0 X-Received: by 10.194.174.36 with SMTP id bp4mr1811549wjc.7.1375870450945; Wed, 07 Aug 2013 03:14:10 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Wed, 7 Aug 2013 03:14:10 -0700 (PDT) X-Originating-IP: [24.234.64.225] In-Reply-To: <52021982.8030108@mozilla.org> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520214F7.8020308@mozilla.org> <52021982.8030108@mozilla.org> Date: Wed, 7 Aug 2013 03:14:10 -0700 Message-ID: From: Trevor Perrin To: Gervase Markham Content-Type: text/plain; charset=ISO-8859-1 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 07 Aug 2013 10:14:18 -0000 On Wed, Aug 7, 2013 at 2:55 AM, Gervase Markham wrote: > On 07/08/13 10:45, Trevor Perrin wrote: >> Presumably the browser would have a table mapping names to key lists, >> and would evaluate a site's cert chain by checking for an intersection >> with all relevant keys in the pin (direct or indirect). > > Yes; this would need to be metadata associated with each cert in the > root store. It would need to be added when roots were added. I was imagining a table which is indexed by CA names, and which maps a CA name to a corresponding list of key hashes. These hashes might correspond to certs in the root store or they might not (e.g., they might correspond to intermediates). Only CAs which had "opted-in" and provided the requisite info to browsers would be in the table. > What happens if a CA requests a change to this mapping? This might > violate the expectations of some users as to which keys they were pinning. When a pinned CA wants to introduce a new root, it would need to update the mapping and wait for the update to propagate before using the new root to sign certs. When a pinned CA wants to remove a revoked or expired root from the mapping, it should be able to do so without problems since browsers would not construct cert paths that require this root. Anyways, if users want to be pinned to a specific key, they should pin to that key directly. If they're pinned to a name, they're trusting the CA and browser vendor to keep the mapping updated in a sensible way. Trevor From gerv@mozilla.org Wed Aug 7 03:47:27 2013 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 C4E7D21F9AA7 for ; Wed, 7 Aug 2013 03:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9sD+NziM7-z for ; Wed, 7 Aug 2013 03:47:22 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6111521E80D7 for ; Wed, 7 Aug 2013 03:47:18 -0700 (PDT) Received: from [192.168.0.22] (cpc2-enfi16-2-0-cust610.hari.cable.virginmedia.com [94.170.82.99]) (Authenticated sender: gerv@mozilla.org) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id AD89AF212C; Wed, 7 Aug 2013 03:47:16 -0700 (PDT) Message-ID: <520225B3.5040701@mozilla.org> Date: Wed, 07 Aug 2013 11:47:15 +0100 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Trevor Perrin References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520214F7.8020308@mozilla.org> <52021982.8030108@mozilla.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 07 Aug 2013 10:47:27 -0000 On 07/08/13 11:14, Trevor Perrin wrote: >> Yes; this would need to be metadata associated with each cert in the >> root store. It would need to be added when roots were added. > > I was imagining a table which is indexed by CA names, and which maps a > CA name to a corresponding list of key hashes. These hashes might > correspond to certs in the root store or they might not (e.g., they > might correspond to intermediates). While others disagree, I think that any attempt by browsers to include information about intermediates in root stores will fail, because intermediates change much more frequently than roots do. The administration would be complex, and the update/outdatedness issues severe. I would not predicate this scheme on browsers shipping a list of intermediate hashes. And I would think you would want to get buy-in from the major browser vendors that they are happy to take on the task of maintaining such a table in order to get the gain of being able to replace cert hashes with names. >> What happens if a CA requests a change to this mapping? This might >> violate the expectations of some users as to which keys they were pinning. > > When a pinned CA wants to introduce a new root, it would need to > update the mapping and wait for the update to propagate before using > the new root to sign certs. Right - but users who were trusting "FooCA" would now be trusting a root they didn't know they were trusting. What happens if two CAs merge, and the acquiring CA wants to have all the roots of the acquired CA now under its brand? > Anyways, if users want to be pinned to a specific key, they should pin > to that key directly. If they're pinned to a name, they're trusting > the CA and browser vendor to keep the mapping updated in a sensible > way. My concern is that this is an abstraction to make things work for people who don't want to think too hard about PKI, but that the abstraction is leaky, and will result in the violation of assumptions. I haven't spent too much time thinking about this and I've already thought of a few. Gerv From trevp@trevp.net Wed Aug 7 04:13:01 2013 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 4E3ED11E80FC for ; Wed, 7 Aug 2013 04:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IJMySOP0npf for ; Wed, 7 Aug 2013 04:12:55 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA5B21F9B03 for ; Wed, 7 Aug 2013 04:12:54 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hj13so3711891wib.5 for ; Wed, 07 Aug 2013 04:12:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=I22CevVDiEKSQ8QRLBtTUCgf6OYD7yqctOuG6QMTMJ4=; b=LN+V61adByzZCWdbP/bH9XfSdunjPXAFHXuyQnmCfNd2jVPcKwoT28vGaIkgHAddqV r1PGhQKTr5tIawKDJm9agmfgVZKkUJq1aq5poYVSpNTWmhx4XWWynAl9TASRv6o0JOpb xxc/NLmojj9q3bkTF3OtXFCK15eM/hjZpvlg07Rwoi8QcQKjWEr3d+QQMGLLrNJQRGX1 hz5ViP7QEYW2vCdIhFTjQUYiAq6yTOMDU80/F8YIfNEq0zzMgYx78xTrVSYXMT1TIk26 67ryWyR7A84XijawR51o7hT60gLkC/uaQ30ztLLwQxnrGlkyFEFHLwk7wqSrzjJIk597 6mxw== X-Gm-Message-State: ALoCoQkLnwXPXYdcJ3Lp1jfAYiRbgLBkAU8zgAh9jCm/bNu0dJnD7kKAu7KaZatksB7gI/Yqo1M9 MIME-Version: 1.0 X-Received: by 10.194.190.201 with SMTP id gs9mr1922911wjc.82.1375873974153; Wed, 07 Aug 2013 04:12:54 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Wed, 7 Aug 2013 04:12:54 -0700 (PDT) X-Originating-IP: [24.234.64.225] In-Reply-To: <520225B3.5040701@mozilla.org> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520214F7.8020308@mozilla.org> <52021982.8030108@mozilla.org> <520225B3.5040701@mozilla.org> Date: Wed, 7 Aug 2013 04:12:54 -0700 Message-ID: From: Trevor Perrin To: Gervase Markham Content-Type: text/plain; charset=ISO-8859-1 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 07 Aug 2013 11:13:01 -0000 On Wed, Aug 7, 2013 at 3:47 AM, Gervase Markham wrote: > On 07/08/13 11:14, Trevor Perrin wrote: >>> Yes; this would need to be metadata associated with each cert in the >>> root store. It would need to be added when roots were added. >> >> I was imagining a table which is indexed by CA names, and which maps a >> CA name to a corresponding list of key hashes. These hashes might >> correspond to certs in the root store or they might not (e.g., they >> might correspond to intermediates). > > While others disagree, I think that any attempt by browsers to include > information about intermediates in root stores will fail, because > intermediates change much more frequently than roots do. The > administration would be complex, and the update/outdatedness issues severe. OK. If pinning to roots is always preferable, the table would only list pins to roots. > I would not predicate this scheme on browsers shipping a list of > intermediate hashes. And I would think you would want to get buy-in from > the major browser vendors that they are happy to take on the task of > maintaining such a table in order to get the gain of being able to > replace cert hashes with names. Absolutely. The browser viewpoint is the most important. >>> What happens if a CA requests a change to this mapping? This might >>> violate the expectations of some users as to which keys they were pinning. >> >> When a pinned CA wants to introduce a new root, it would need to >> update the mapping and wait for the update to propagate before using >> the new root to sign certs. > > Right - but users who were trusting "FooCA" would now be trusting a root > they didn't know they were trusting. If you care about the specific keys you're pinned to, you should pin to specific keys. If you pin to "FooCA", you're trusting them to add and remove keys from the named set. You're giving up some control for convenience. > What happens if two CAs merge, and the acquiring CA wants to have all > the roots of the acquired CA now under its brand? It adds them to the mapping for its brand. >> Anyways, if users want to be pinned to a specific key, they should pin >> to that key directly. If they're pinned to a name, they're trusting >> the CA and browser vendor to keep the mapping updated in a sensible >> way. > > My concern is that this is an abstraction to make things work for people > who don't want to think too hard about PKI Yes! But that's almost everyone. > , but that the abstraction is > leaky, and will result in the violation of assumptions. Hmm.. Not sure what you mean, specifically. Trevor From gerv@mozilla.org Wed Aug 7 05:10:50 2013 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 33D9D11E8138 for ; Wed, 7 Aug 2013 05:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEkF0Tyg4hvk for ; Wed, 7 Aug 2013 05:10:44 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id CDB3311E811E for ; Wed, 7 Aug 2013 05:10:43 -0700 (PDT) Received: from [192.168.0.22] (cpc2-enfi16-2-0-cust610.hari.cable.virginmedia.com [94.170.82.99]) (Authenticated sender: gerv@mozilla.org) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 9A5A0F223B; Wed, 7 Aug 2013 05:10:42 -0700 (PDT) Message-ID: <52023941.8010602@mozilla.org> Date: Wed, 07 Aug 2013 13:10:41 +0100 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Trevor Perrin References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520214F7.8020308@mozilla.org> <52021982.8030108@mozilla.org> <520225B3.5040701@mozilla.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 07 Aug 2013 12:10:50 -0000 On 07/08/13 12:12, Trevor Perrin wrote: > Hmm.. Not sure what you mean, specifically. I mean, I think people who want to use pinning will expect the set of certificates (and associated security practices) they are pinning to not to change under their feet. This scheme means that they will. They might also expect to define a pin and have it work everywhere HPKP is supported, in exactly the same way. This scheme (due to client version skew) means that it may not. Gerv From jeremy.rowley@digicert.com Wed Aug 7 06:25:16 2013 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 4441121F9AE7 for ; Wed, 7 Aug 2013 06:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqPBuUxVABtN for ; Wed, 7 Aug 2013 06:25:09 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 6522F11E812C for ; Wed, 7 Aug 2013 06:24:44 -0700 (PDT) Received: from JROWLEYL1 (unknown [67.137.52.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id ABDB28FA089 for ; Wed, 7 Aug 2013 07:24:40 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1375881880; bh=DR9DwgTtIuaGkId7Wrwv3b6JosoiNUr7UhpqWL5sih8=; h=Reply-To:From:To:References:In-Reply-To:Subject:Date; b=bJiASJbm+lSccIah39R2IBBzgQMbg3aKNBcGoTZc+GcVSZnG0RtuaeDLfvyVbDkq7 fusB2hUiKxmHLaD+K46bOWDwEnrvbeiuiDla8Lo2VIOGQM0b1tTm9kBbNYSlFvRHAC CSx8Z4uVikFV6cJHPqTRNXQ/suikxFvZk/mNMBx4= From: "Jeremy Rowley" To: "'websec'" References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520214F7.8020308@mozilla.org> <52021982.8030108@mozilla.org> <520225B3.5040701@mozilla.org> <52023941.8010602@mozilla.org> In-Reply-To: <52023941.8010602@mozilla.org> Date: Wed, 7 Aug 2013 07:24:44 -0600 Organization: DigiCert Message-ID: <001b01ce9371$7bd90210$738b0630$@digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJoJKS5/1/Jv2JXKWhm99jqPYGDVAJNKJejAdJQI9sCGoZA7wM5pAdUAiWKukcBIDPIBwKEztKWA317OekB69JZTwJi9YGoAc8A35ECm3ZRowHLcgZ4AnEkISmXWQ1eEA== Content-Language: en-us Subject: Re: [websec] #58: Should we pin only SPKI, or also names X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jeremy.rowley@digicert.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 13:25:16 -0000 For pinning to a specific CA, the end user doesn't care which root they are trusting. They are indicating trust in an entire PKI. In this case, I think they expect the set of certificates to change, but have delegated this trust to a set entity. This is important for two reasons: 1) CAs can partly mitigate the "too big to fail" routinely cited as a major weakness in the industry by liming the number of certs signed to each intermediate/root and 2) enterprises utilizing a completely managed PKI solution can gain the benefits of pinning, increasing the potential for adoption and use of pinning. Jeremy -----Original Message----- From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf Of Gervase Markham Sent: Wednesday, August 07, 2013 6:11 AM To: Trevor Perrin Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names On 07/08/13 12:12, Trevor Perrin wrote: > Hmm.. Not sure what you mean, specifically. I mean, I think people who want to use pinning will expect the set of certificates (and associated security practices) they are pinning to not to change under their feet. This scheme means that they will. They might also expect to define a pin and have it work everywhere HPKP is supported, in exactly the same way. This scheme (due to client version skew) means that it may not. Gerv _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec From gerv@mozilla.org Wed Aug 7 06:27:24 2013 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 7CA0121F9E27 for ; Wed, 7 Aug 2013 06:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.664 X-Spam-Level: X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id no4jifcXDwFV for ; Wed, 7 Aug 2013 06:27:19 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC5C21E8124 for ; Wed, 7 Aug 2013 06:27:08 -0700 (PDT) Received: from [192.168.0.22] (cpc2-enfi16-2-0-cust610.hari.cable.virginmedia.com [94.170.82.99]) (Authenticated sender: gerv@mozilla.org) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 4F758F2248; Wed, 7 Aug 2013 06:27:06 -0700 (PDT) Message-ID: <52024B29.9010600@mozilla.org> Date: Wed, 07 Aug 2013 14:27:05 +0100 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: jeremy.rowley@digicert.com References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520214F7.8020308@mozilla.org> <52021982.8030108@mozilla.org> <520225B3.5040701@mozilla.org> <52023941.8010602@mozilla.org> <001b01ce9371$7bd90210$738b0630$@digicert.com> In-Reply-To: <001b01ce9371$7bd90210$738b0630$@digicert.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'websec' Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 07 Aug 2013 13:27:24 -0000 Hi Jeremy, On 07/08/13 14:24, Jeremy Rowley wrote: > For pinning to a specific CA, the end user doesn't care which root they are > trusting. They are indicating trust in an entire PKI. In this case, I > think they expect the set of certificates to change, but have delegated this > trust to a set entity. This is important for two reasons: 1) CAs can partly > mitigate the "too big to fail" routinely cited as a major weakness in the > industry by liming the number of certs signed to each intermediate/root and > 2) enterprises utilizing a completely managed PKI solution can gain the > benefits of pinning, increasing the potential for adoption and use of > pinning. My apologies, but I am having difficulty tying your points (from "This is important..." onwards) to what I was saying. Can you elaborate? Gerv > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf Of > Gervase Markham > Sent: Wednesday, August 07, 2013 6:11 AM > To: Trevor Perrin > Cc: websec > Subject: Re: [websec] #58: Should we pin only SPKI, or also names > > On 07/08/13 12:12, Trevor Perrin wrote: >> Hmm.. Not sure what you mean, specifically. > > I mean, I think people who want to use pinning will expect the set of > certificates (and associated security practices) they are pinning to not to > change under their feet. This scheme means that they will. They might also > expect to define a pin and have it work everywhere HPKP is supported, in > exactly the same way. This scheme (due to client version > skew) means that it may not. > > Gerv > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From jeremy.rowley@digicert.com Wed Aug 7 06:35:10 2013 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 2726421F99C2 for ; Wed, 7 Aug 2013 06:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Rt2UhnidED1 for ; Wed, 7 Aug 2013 06:35:05 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id D615321F93D4 for ; Wed, 7 Aug 2013 06:35:05 -0700 (PDT) Received: from JROWLEYL1 (unknown [67.137.52.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 702CB8FA86B; Wed, 7 Aug 2013 07:35:05 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1375882505; bh=1KYZ8EZGk1HhelOKNIqUthbMbIWxs6hOAUIbhQMStOM=; h=Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date; b=Ky5Zviz92ai2drNXrD8EGZHpgHdv8zN4A7HjrzqyIVRAyOVr/D9ztsu8uySh7pr4/ H7DdlhsHBFRnYGz3X44f0K1typZNV4ZyKZxWyo7Zypq87fc8fqCvlu43+DHI3/FCxP CdaphYdzNgxjDGbzunHHFjlvH7HedWRjMT/MGvwY= From: "Jeremy Rowley" To: "'Gervase Markham'" References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520214F7.8020308@mozilla.org> <52021982.8030108@mozilla.org> <520225B3.5040701@mozilla.org> <52023941.8010602@mozilla.org> <001b01ce9371$7bd90210$738b0630$@digicert.com> <52024B29.9010600@mozilla.org> In-Reply-To: <52024B29.9010600@mozilla.org> Date: Wed, 7 Aug 2013 07:35:09 -0600 Organization: DigiCert Message-ID: <002b01ce9372$f041ec10$d0c5c430$@digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJoJKS5/1/Jv2JXKWhm99jqPYGDVAJNKJejAdJQI9sCGoZA7wM5pAdUAiWKukcBIDPIBwKEztKWA317OekB69JZTwJi9YGoAc8A35ECm3ZRowHLcgZ4AnEkISkBX1oWQwFkgIQ9l0LxTMA= Content-Language: en-us Cc: 'websec' Subject: Re: [websec] #58: Should we pin only SPKI, or also names X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jeremy.rowley@digicert.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 13:35:10 -0000 I suppose it wasn't directly related to your point. I was simply = emphasizing why pinning to a CA is an important option. There are = current CA-customer relationships that would benefit and use a pin to a = CA over a root certificate. -----Original Message----- From: Gervase Markham [mailto:gerv@mozilla.org]=20 Sent: Wednesday, August 07, 2013 7:27 AM To: jeremy.rowley@digicert.com Cc: 'websec' Subject: Re: [websec] #58: Should we pin only SPKI, or also names Hi Jeremy, On 07/08/13 14:24, Jeremy Rowley wrote: > For pinning to a specific CA, the end user doesn't care which root=20 > they are trusting. They are indicating trust in an entire PKI. In=20 > this case, I think they expect the set of certificates to change, but=20 > have delegated this trust to a set entity. This is important for two=20 > reasons: 1) CAs can partly mitigate the "too big to fail" routinely=20 > cited as a major weakness in the industry by liming the number of=20 > certs signed to each intermediate/root and > 2) enterprises utilizing a completely managed PKI solution can gain=20 > the benefits of pinning, increasing the potential for adoption and use = > of pinning. My apologies, but I am having difficulty tying your points (from "This = is important..." onwards) to what I was saying. Can you elaborate? Gerv > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On=20 > Behalf Of Gervase Markham > Sent: Wednesday, August 07, 2013 6:11 AM > To: Trevor Perrin > Cc: websec > Subject: Re: [websec] #58: Should we pin only SPKI, or also names >=20 > On 07/08/13 12:12, Trevor Perrin wrote: >> Hmm.. Not sure what you mean, specifically. >=20 > I mean, I think people who want to use pinning will expect the set of=20 > certificates (and associated security practices) they are pinning to=20 > not to change under their feet. This scheme means that they will. They = > might also expect to define a pin and have it work everywhere HPKP is=20 > supported, in exactly the same way. This scheme (due to client version > skew) means that it may not. >=20 > Gerv > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec >=20 From ynir@checkpoint.com Wed Aug 7 08:53:34 2013 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 BF4C421E8143 for ; Wed, 7 Aug 2013 08:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.511 X-Spam-Level: X-Spam-Status: No, score=-10.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrPnu+OhacLT for ; Wed, 7 Aug 2013 08:53:28 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7F43321E8137 for ; Wed, 7 Aug 2013 08:53:27 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r77FrOU4009532; Wed, 7 Aug 2013 18:53:24 +0300 X-CheckPoint: {52026D74-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Wed, 7 Aug 2013 18:53:23 +0300 From: Yoav Nir To: Trevor Perrin Thread-Topic: [websec] #58: Should we pin only SPKI, or also names Thread-Index: AQHOjHagv3/BmvZ4wU6WrbkIw+Bd/ZmAXZOAgAADk4CAAHu6gIAIRDGAgAA0tQCAAAIEgIAAAsgAgAACowCAAAVKAIAAXsaA Date: Wed, 7 Aug 2013 15:53:23 +0000 Message-ID: References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520214F7.8020308@mozilla.org> <52021982.8030108@mozilla.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.54] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 111581a387ac895af907077791836970cbec21ba38 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <642D94392020EF48AB82B044521AF147@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 07 Aug 2013 15:53:34 -0000 On Aug 7, 2013, at 1:14 PM, Trevor Perrin wrote: > On Wed, Aug 7, 2013 at 2:55 AM, Gervase Markham wrote: >> On 07/08/13 10:45, Trevor Perrin wrote: >>> Presumably the browser would have a table mapping names to key lists, >>> and would evaluate a site's cert chain by checking for an intersection >>> with all relevant keys in the pin (direct or indirect). >>=20 >> Yes; this would need to be metadata associated with each cert in the >> root store. It would need to be added when roots were added. >=20 > I was imagining a table which is indexed by CA names, and which maps a > CA name to a corresponding list of key hashes. These hashes might > correspond to certs in the root store or they might not (e.g., they > might correspond to intermediates). >=20 > Only CAs which had "opted-in" and provided the requisite info to > browsers would be in the table. I'm only wondering where I get a copy of that table and who maintains it. H= aving a different one maintained by each browser vendor IMO makes the Inter= net worse, not better. So do we have a volunteer to maintain it, maintain a= stable link to it, receive updates from numerous new and old certificate v= endors, and verify those updates with the browser vendors (so you can't reg= ister a new CA in the list if you aren't also trying to get in listed in th= e browser verndors' lists of trusted CAs. BTW: it's OK to pin to trust anchors, but it also works to pin to the leaf = public key (with a "spare" public key to be used in the next certificate). = Surprisingly, pinning to intermediate CAs combines the worst of both option= s (out of your control like the CA, and changes often like the end entity) Yoav From trevp@trevp.net Wed Aug 7 20:39:24 2013 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 6509B11E81A4 for ; Wed, 7 Aug 2013 20:39:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hf07WrX-exoa for ; Wed, 7 Aug 2013 20:39:10 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id CEDDE11E819D for ; Wed, 7 Aug 2013 20:38:54 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id f14so118609wiw.7 for ; Wed, 07 Aug 2013 20:38:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tZZ/RVHTd8Ce9IHzCDEP2/AgK1zjoNAteHgVeeXp950=; b=Yn9AVYpDPrRmsdaQx4jNm1+X2TgQvlBsF+vo4tO7gjuNczeZn8KaB3oCXN95+FZeM3 3CRLM66Hz0yK3lTWIoCSnxxsi3N49805qxH5pze6Oo+BwTAlNshg+Q9MEJTPZV5U1wLO aaU6PlnEPDetXrOpuc35fgNnZaYdenzedOkxg2oezHlOB0dKKXuNeGItk7AE9M5SOlOU cFv6/XWcqWr0l7BtxDHQJD1dEyNbZ9QXO9Hy36BU+4T5op9+teq5wF2gmG9jURqjx0jn sugNj/HJQuqe/W9XSdQCfcdQPHqNkXdKvjvCf6IUKn5bh67wXs8ZPab82cPawpbIjs6N 2A2Q== X-Gm-Message-State: ALoCoQnIGPqxcWDjes1IBWrM2iCZPehYe2vzs+X4JzA2A60Jktyf1SHUwfb4YB7TRsOSNPVRI1/A MIME-Version: 1.0 X-Received: by 10.180.205.236 with SMTP id lj12mr3903723wic.22.1375933132725; Wed, 07 Aug 2013 20:38:52 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Wed, 7 Aug 2013 20:38:52 -0700 (PDT) X-Originating-IP: [50.37.25.208] In-Reply-To: References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520214F7.8020308@mozilla.org> <52021982.8030108@mozilla.org> Date: Wed, 7 Aug 2013 20:38:52 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 08 Aug 2013 03:39:24 -0000 On Wed, Aug 7, 2013 at 8:53 AM, Yoav Nir wrote: > > On Aug 7, 2013, at 1:14 PM, Trevor Perrin wrote: >> >> Only CAs which had "opted-in" and provided the requisite info to >> browsers would be in the table. > > I'm only wondering where I get a copy of that table and who maintains it. CAs and Browsers would have to work that out. I don't know what their preferred coordination method would be. Trevor From trevp@trevp.net Wed Aug 7 22:25:48 2013 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 30EB411E81A4 for ; Wed, 7 Aug 2013 22:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZy+9uAdo4L9 for ; Wed, 7 Aug 2013 22:25:42 -0700 (PDT) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD9811E80DF for ; Wed, 7 Aug 2013 22:25:40 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id t57so2168036wes.24 for ; Wed, 07 Aug 2013 22:25:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TMop12kG1yv9aozZEGCL3X5RQLk0iIJRWKC+i2T71XQ=; b=PZldBJ5v2I7mnuzUfcOROpqV0tVKM9ZJv4r8sWB8h3SI0um+GjfaZEkWpLGmIW70IY 6eWi6C93S6a1LirycKEMEZfdzhKNbBkZn1EF835DNUKb08dRUTwrfom97+w7F9UKUALX htU5hQqawcmU0fXzh2CMBwgJ/Yu73nzrQyuw5w3jC0Dlfi+80W2w5rHAYl3T5K3Up4TI NF89qBvXlugmGO6ddAtCVQVLa4NjHTg37rk/RT9GpkbnehfwNDaB1UM0AkyyU4mlO6wB hYMfzgKUv4bd8A1bmlxqiLlIeg/H7vFM54MY9gnHzjLAuDFg2OEKt11fqrl7Zm0/jgM0 OlIQ== X-Gm-Message-State: ALoCoQl/+iv8S1iiIkIEvTrOBO1n1UbA/gJ5zphvKNJ4aiYeiu/Re4rKGoqv6pGLeHPyKWs/FO0M MIME-Version: 1.0 X-Received: by 10.180.205.236 with SMTP id lj12mr4071302wic.22.1375939539327; Wed, 07 Aug 2013 22:25:39 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Wed, 7 Aug 2013 22:25:39 -0700 (PDT) X-Originating-IP: [50.37.25.208] In-Reply-To: References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> <51FA1C35.1090005@mozilla.org> <4B4A645A-793F-4276-96BF-FBA5BA740632@checkpoint.com> <51FA26AD.2020405@gondrom.org> <0C788DC3-4C7F-47D4-B0A6-54E94FC5EAD0@checkpoint.com> Date: Wed, 7 Aug 2013 22:25:39 -0700 Message-ID: From: Trevor Perrin To: ryan-ietfhasmat@sleevi.com Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 08 Aug 2013 05:25:48 -0000 On Tue, Aug 6, 2013 at 2:51 PM, Ryan Sleevi wrote: > On Tue, August 6, 2013 1:02 pm, Trevor Perrin wrote: >> On Tue, Aug 6, 2013 at 1:51 AM, Trevor Perrin wrote: >> > On Mon, Aug 5, 2013 at 3:37 AM, Yoav Nir wrote: >> > >> > I wonder if HPKP should go in both a Response header *and* a well-known >> > URI? >> >> >> Another alternative is to return HPKP as a TLS ServerHello Extension, >> sent when the client requests it (same as TACK or Certificate >> Transparency). > > While appealing from a 'spec purity' point, I think the idea of using it > as a ServerHello extension is a concept that's more or less DOA, in that > it still leaves an unfortunate gap of servers that will not be able to do > anything to allow clients to discover this policy. > > I think the cons for it definitely outweigh the pros. Even though there is > general interest in fixing the negotiation problem, it'd be a real shame > to lose an extremely valuable security policy by forcing it to go down a > path we know doesn't universally work. Further, I think it vastly > underestimates the work required to get it practically adopted - even if > two widely-used SSL stacks are easily amenable to it, you completely miss > out for platforms such as iOS, Android, OS X, or Windows, short of > platform upgrades, which we know are less than frequent. I think you're overstating the challenges with TLS Extensions. In the short term they're a hassle. But once we patch the things that need patching and kill or workaround buggy middleboxes, there are advantages to having TLS policy in the TLS layer. I'm fine with HPKP being skeptical and wanting to avoid this. But the problems that this idea (and others) were trying to fix still need resolution. Joe's email summarizes the main problems: """ ...two issues that I think are real impediments to servers deploying HPKP and doing so correctly: (a) header bloat (600 bytes of for a site requiring 10 pins) (b) inadvertent HPKP hole-punching when resources are accidentally served without headers set. """ I would add: "discoverability by crawlers", which Joe dismisses but is actually important. It could be as simple as saying a site SHOULD always return an HPKP response for the index page (or robots.txt). Anyways, if we're keeping the HPKP response header, I'd like to understand how we can modify things and make recommendations to address these. Trevor From ynir@checkpoint.com Wed Aug 7 23:09:02 2013 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 A23A921F9EF2 for ; Wed, 7 Aug 2013 23:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6sCcI3YPvqe for ; Wed, 7 Aug 2013 23:08:56 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3198621F9ADC for ; Wed, 7 Aug 2013 23:08:55 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7868sts001434 for ; Thu, 8 Aug 2013 09:08:54 +0300 X-CheckPoint: {520335F6-1-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Thu, 8 Aug 2013 09:08:54 +0300 From: Yoav Nir To: websec Thread-Topic: [websec] #58: Should we pin only SPKI, or also names Thread-Index: AQHOjHagv3/BmvZ4wU6WrbkIw+Bd/ZmAXZOAgAADk4CAAHu6gIAIRDGAgAA0tQCAAAIEgIAAAsgAgAACowCAAAVKAIAAXsaAgADFHACAACnrgA== Date: Thu, 8 Aug 2013 06:08:53 +0000 Message-ID: <09644FE8-F979-4604-BC58-6622A632ECE3@checkpoint.com> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520214F7.8020308@mozilla.org> <52021982.8030108@mozilla.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.186] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 1180ccb663425e8fbb6050f54efa16267cd26babc9 Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 08 Aug 2013 06:09:02 -0000 On Aug 8, 2013, at 6:38 AM, Trevor Perrin wrote: > On Wed, Aug 7, 2013 at 8:53 AM, Yoav Nir wrote: >>=20 >> On Aug 7, 2013, at 1:14 PM, Trevor Perrin wrote: >>>=20 >>> Only CAs which had "opted-in" and provided the requisite info to >>> browsers would be in the table. >>=20 >> I'm only wondering where I get a copy of that table and who maintains it= . >=20 > CAs and Browsers would have to work that out. I don't know what their > preferred coordination method would be. Yes. But they haven't so far. Since it's something that the CAs and browser= s should work out, the obvious candidate organization is the CA/Browser for= um. However, that organization contains neither all CAs not all browsers. I= t's easy to think that the set of browsers is {Chrome, IE, Firefox, Safari,= Opera}, but there are dozens more. Relying on each one of them (including = the small ones) getting information about labels from all CAs doesn't scale= . Even more, the web server administrators need access to that list of labe= ls and what it means. So I suggest we don't include this now. Instead we make sure that whatever = the result of #60 is, that HPKP is extensible. Later, when/if the CA/BF can= get us a stable link to a list of labels, we can do a quick update documen= t and add it then. Objections? Yoav From mnot@mnot.net Thu Aug 8 05:36:00 2013 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 C914621F9EA8 for ; Thu, 8 Aug 2013 05:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmlonTAO109N for ; Thu, 8 Aug 2013 05:35:56 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC9721F9EB5 for ; Thu, 8 Aug 2013 05:35:56 -0700 (PDT) Received: from [192.168.2.194] (unknown [84.176.44.224]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9565150A85 for ; Thu, 8 Aug 2013 08:35:52 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <4CF90F65-62CE-4AE0-9113-932F93A98782@mnot.net> Date: Thu, 8 Aug 2013 14:35:46 +0200 To: "" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Thu, 08 Aug 2013 09:54:40 -0700 Subject: [websec] Well-known URIs 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, 08 Aug 2013 12:36:00 -0000 Hi, I see there's discussion of well-known URIs for Websec over here. Just a few points that may help=85 or not. 1. Well-known URIs are designed for cases where the client wants to get = a bunch of *related* data together; as such, a general framework is = encouraged, as long as the use cases are similar.=20 This is why I don't like hostmeta; it's a bucket for anything you want = to throw in there, which means that over time, the client will be = getting a lot of information they don't want, which will necessitate a = query language, which is just nasty overkill. At the other end of the = spectrum, having a single-use well-known URI in the critical path (or = even not) for a browser is similarly Not A Good Idea. 2. Discovering whether a well-known URI is present on a given host = without much overhead is the use case for browser hints: = . = Looking for a better name for that one=85 3. Alternatively, if browsers are pre connecting, they could use the = conn to fetch a well-known URI, as long as it was cheap to fetch. That = policy file could even control how aggressively the browser pre-connects = (two birds, one stone=85). Hope this helps, -- Mark Nottingham http://www.mnot.net/ From palmer@google.com Thu Aug 8 12:31:59 2013 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 D78B31F0D52 for ; Thu, 8 Aug 2013 12:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwYx8JFQ6L39 for ; Thu, 8 Aug 2013 12:31:59 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 69BA321F8EC3 for ; Thu, 8 Aug 2013 12:31:59 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k5so2579405iea.4 for ; Thu, 08 Aug 2013 12:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xK3f4DxCBQQATdTD2Tmfxok4p6/HbyT305/qpx7d5ac=; b=nU1ElySMrZ/l3eDr+w2ZN9H8nNHE12Wo06B7Qp3KMJJu8wiQH8q+z66rT+JzYK+5b9 cubcOg9AGWTdK1L5tIU0ZzJuacUQaLpu/VwphkrUzC59JZ5nV4uz8CZ7uICJZ+9e3T3V x13OaveR90f3hkJ89UaNGIC2K7D8qzGVtY0gV2nyzCLji0DkigWu0y9E4v6LEMVBYTwq X7Sc1Bq6wt1xeMJ1qC1sqgs76m3Jy9zwqdUz+hM14+GrbUMlmeX1YJSZ/kyVIGGT12PD 4WAXrLuV92s6zuqtqIzaDVzyVhxUVmDuzd3u4l4P0Bg08QdYx2tYWIDhh9YQBG5yZ6Gc sDiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xK3f4DxCBQQATdTD2Tmfxok4p6/HbyT305/qpx7d5ac=; b=E3svLv2SoI9i6K99f/bIXB9c1X5tugk4bP9QieMwGerUphojvT0zOuyCvapFn16PnJ QNXAkaPamwLYbjVj7Rx3Cq5n5Hi0Njmq0XKJx9rA38AZ1HCobuV9ug/5Z8S0moklAvfW +wWcIsWchOBz13uQbBX9ssqhB2MgyQqdP4OYvEw+q1PvMzfL3LY6HvJdBzDuRL4Mg2QR Aj1CV6HezMEho2srhzMB//mir7Iah5f4P3fznzMgQTyF2hSipEUOCfsSNI44EHid9/yG 8NGKSOxeeaCLpw2ib20d6gx1DSe7qX91EslFHO8s9froz5PqrgI32VFTFqn7+EuZ/ILX GTyQ== X-Gm-Message-State: ALoCoQkrRod7ibBn8iu4zfbFFVjVxxtbE+VbEJ6T7fVcGEGg/KyKAbHJAzpUkbd6PRlL+Vjmr50/sbwa6fh5iKBRjOuIb3QrTIheYyFU74K71/zIyPbefveq4js0IsZDapbRwZ74WewzVXHHv/oK1yqN/KhflcDSysQ6Oj+RGHFFKT83YWMmWwRXeLCf42vIAnb1dx4ObYjd MIME-Version: 1.0 X-Received: by 10.43.19.200 with SMTP id ql8mr2843417icb.72.1375990318854; Thu, 08 Aug 2013 12:31:58 -0700 (PDT) Received: by 10.64.240.71 with HTTP; Thu, 8 Aug 2013 12:31:58 -0700 (PDT) In-Reply-To: <4CF90F65-62CE-4AE0-9113-932F93A98782@mnot.net> References: <4CF90F65-62CE-4AE0-9113-932F93A98782@mnot.net> Date: Thu, 8 Aug 2013 12:31:58 -0700 Message-ID: From: Chris Palmer To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [websec] Well-known URIs 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, 08 Aug 2013 19:32:00 -0000 On Thu, Aug 8, 2013 at 5:35 AM, Mark Nottingham wrote: > 1. Well-known URIs are designed for cases where the client wants to get a= bunch of *related* data together; as such, a general framework is encourag= ed, as long as the use cases are similar. > > This is why I don't like hostmeta; it's a bucket for anything you want to= throw in there, which means that over time, the client will be getting a l= ot of information they don't want, which will necessitate a query language,= which is just nasty overkill. At the other end of the spectrum, having a s= ingle-use well-known URI in the critical path (or even not) for a browser i= s similarly Not A Good Idea. Can you say clearly what else we should stuff into the W-K URI for HPKP? What other working groups and standards bodies are we going to have to reach consensus with? > 3. Alternatively, if browsers are pre connecting, they could use the conn= to fetch a well-known URI, as long as it was cheap to fetch. That policy f= ile could even control how aggressively the browser pre-connects (two birds= , one stone=E2=80=A6). You just said it should *not* become a catch-all bucket. From tobias.gondrom@gondrom.org Thu Aug 8 13:18:30 2013 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 BF10611E821D for ; Thu, 8 Aug 2013 13:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7P0GqlXwX6+5 for ; Thu, 8 Aug 2013 13:18:26 -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 DA42011E8200 for ; Thu, 8 Aug 2013 13:18:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=YFMJW+Z/x+DISKgVM57+sEZbU4L6L/g2303E8xIMssx/aBep2EQjDIHsC4AQ+DAiXqHQSTJcq4ZhdbAN8sJy31EWEsvAHm/ei9BG2hu2OCPpQVlR6cg+ehZWNE6eo9TI; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 13323 invoked from network); 8 Aug 2013 22:18:23 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.64?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 8 Aug 2013 22:18:23 +0200 Message-ID: <5203FD0E.40506@gondrom.org> Date: Thu, 08 Aug 2013 21:18:22 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: websec@ietf.org References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520214F7.8020308@mozilla.org> <52021982.8030108@mozilla.org> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 08 Aug 2013 20:18:30 -0000 Hi, On 08/08/13 04:38, Trevor Perrin wrote: > On Wed, Aug 7, 2013 at 8:53 AM, Yoav Nir wrote: >> On Aug 7, 2013, at 1:14 PM, Trevor Perrin wrote: >>> Only CAs which had "opted-in" and provided the requisite info to >>> browsers would be in the table. >> I'm only wondering where I get a copy of that table and who maintains it. > CAs and Browsers would have to work that out. I don't know what their > preferred coordination method would be. > Hm, I did expect we could do the name pinning - if we want to do it - without additional coordination at all for this. If you pin to the name in the cert, this would only allow certs from this CA to be trusted for this specific domain. As in the repository of the browsers as it is today already. What did I miss here? And I would strongly advise against any additional coordination exercises as this makes the adoption more complicated and less likely. Best regards, Tobias > Trevor > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From palmer@google.com Thu Aug 8 13:26:44 2013 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 2B99E21F9AE3 for ; Thu, 8 Aug 2013 13:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0Y2N7fM76zg for ; Thu, 8 Aug 2013 13:26:43 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id BDFC921F9B19 for ; Thu, 8 Aug 2013 13:26:43 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id qd12so2813032ieb.0 for ; Thu, 08 Aug 2013 13:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bfozpyo3JmKil2BMzClszm/GSH3pz5WjJDAZHZO4N7U=; b=M5SfUzUHG5gesK/rpIIlbvBkjCFxRDNitckLsG0LBnJmZq77tIfBhDxoIIRDRYPJN3 dtnc5Zlw9yyWm/d/q/9WYytJG7EuS1Z1Q8BCVCthqGmJOFzLZmCyGAuzsu/5/a9eSb82 DN4W/UvKc78318ux10yQnKsowO+KNz/7uizixiOfTtZAwHDR+q/Z6fzGYYAKxZXvUKJ8 E8YpVMcGOR0gcYloALm8hdXL71x5i03Ze+WiZSaIPbJur9/4Qtd1UO0CKBwGLydikZF1 8Xka3TJ9wI68QsV4z6UVB0h4FTT9FqjLXDzuJHFQxUiNLqLf/azzbhvLlyNzDVKMcxWt Ufmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bfozpyo3JmKil2BMzClszm/GSH3pz5WjJDAZHZO4N7U=; b=d7PGK1eMETgTJ9VlU492Zssr7LRdTNNUoknCBtOACHwMolIjvwCE2oyMGcGkORrMk8 ACIJzPd2bHzX6PLsXPgsYrKw9Wpw4UB0ak35/dxwUgMmZ0Ks72wB7rpkA+wxyJelGEbz vp4Z0T4yKylv8wHX/Qm5lUyCCKM5WW6tU7gXrDPDeIt6FrtFBu6+kPRfPUsFwk/BuKeE giIVnmxNjp4PptjmzRcGowOGHlQX02mR7ZRTW1kIO/31fM2lLRj60mFU7flUrqlzzyeg 7boEmiA+ejYh2Im7RYEm2vwgNFtgANqiOudIXqerjvzY0aSM0iaLlUrQ2Kma1ecRLlME IdKg== X-Gm-Message-State: ALoCoQkx0f3Lq345xEoZCTwHfwKqGjpmBHkCSiC0aVEHgkzGBFhZV60GEEVl/ikcS4cnLSYlLXKHDM9TEM4iL6aW5e7TRYwx6SUMPfcX2DE9S8VSz92UwHDAy4tIYyoTkjO2aTg531gWcE26hTaBwWreU51PPmKUImMeYEkyy6KbtuTSAZ5ziJ/tTc5l8YEJtUP4MttI0sLS MIME-Version: 1.0 X-Received: by 10.42.210.147 with SMTP id gk19mr761016icb.54.1375993602223; Thu, 08 Aug 2013 13:26:42 -0700 (PDT) Received: by 10.64.240.71 with HTTP; Thu, 8 Aug 2013 13:26:42 -0700 (PDT) In-Reply-To: <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> Date: Thu, 8 Aug 2013 13:26:42 -0700 Message-ID: From: Chris Palmer To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 08 Aug 2013 20:26:44 -0000 On Tue, Aug 6, 2013 at 11:19 PM, Yoav Nir wrote: > That is not to say we must not do this, but we must not do this without a= registry for CA strings. The go to body for registries at the IETF is IANA= , but I don't think we've ever had an IANA registry for brand names. So unl= ess we can get some body (the CA/Browser Forum ?) to create such a registry= and provide a stable link that we can reference, I think this is a non-sta= rter. Even with such a registry, I don't see consensus for this. With such a registry, I'd support it. It solves two problems: ease-of-use for site operators, and (a distant second, but perception matters) response header size. But, setting up the registry is a probably-not-trivial job. Is anybody interested in doing it? Is there buy-in from CAs (Phill?)? From ynir@checkpoint.com Thu Aug 8 13:27:38 2013 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 AF66211E8200 for ; Thu, 8 Aug 2013 13:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.514 X-Spam-Level: X-Spam-Status: No, score=-10.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QA9IZ20Bj6+B for ; Thu, 8 Aug 2013 13:27:32 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF0121F9C72 for ; Thu, 8 Aug 2013 13:27:32 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r78KRSqO026957; Thu, 8 Aug 2013 23:27:28 +0300 X-CheckPoint: {5203FF30-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Thu, 8 Aug 2013 23:27:26 +0300 From: Yoav Nir To: Chris Palmer Thread-Topic: [websec] Well-known URIs Thread-Index: AQHOlFgB2fNLbEWVFkSgl8GkYD3KkJmLgOoAgAAPfoA= Date: Thu, 8 Aug 2013 20:27:26 +0000 Message-ID: References: <4CF90F65-62CE-4AE0-9113-932F93A98782@mnot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.237] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11f42b9a8d2aff8f29b6775ee0d419e64a417f8d02 Content-Type: text/plain; charset="us-ascii" Content-ID: <5F0CEED104D2D240AA979EA240CFA19F@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mark Nottingham , "" Subject: Re: [websec] Well-known URIs 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, 08 Aug 2013 20:27:38 -0000 Hi Chris On Aug 8, 2013, at 10:31 PM, Chris Palmer wrote: > On Thu, Aug 8, 2013 at 5:35 AM, Mark Nottingham wrote: >=20 >> 1. Well-known URIs are designed for cases where the client wants to get = a bunch of *related* data together; as such, a general framework is encoura= ged, as long as the use cases are similar. >>=20 >> This is why I don't like hostmeta; it's a bucket for anything you want t= o throw in there, which means that over time, the client will be getting a = lot of information they don't want, which will necessitate a query language= , which is just nasty overkill. At the other end of the spectrum, having a = single-use well-known URI in the critical path (or even not) for a browser = is similarly Not A Good Idea. >=20 > Can you say clearly what else we should stuff into the W-K URI for > HPKP? What other working groups and standards bodies are we going to > have to reach consensus with? The answer to those questions is "nothing" and "none". let's assume the format is JSON, we could call the resource https://www.exa= mple.com/.well-known/TransportSecurity.json , and it could be formatted lik= e this: { "HPKP": { "max_age": 2592000, "include_subdomains": "false", "pins": [ { "alg": "sha1" "hash": "aQWqfl0MQRwcM+3uffZ08Rttods=3D" }, { "alg": "sha256" "hash": "Lbl5D9eR4PLiaOUSeO6sue2QrSvpB31F4mte/4D75xM=3D" }, ] } } Then if someone wants to add HSTS into this, they're welcome to it, but the= y'll need their own document to do it. Yoav From palmer@google.com Thu Aug 8 13:33:09 2013 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 D4B4311E821E for ; Thu, 8 Aug 2013 13:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqJty8KoG1hi for ; Thu, 8 Aug 2013 13:33:09 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A064411E820E for ; Thu, 8 Aug 2013 13:33:07 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id 10so2753252ied.16 for ; Thu, 08 Aug 2013 13:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F9K9bgHxasb0CenAEf+0idBva4OFL5T9xQuTGrzmqwM=; b=lLhz810Ljv5WMrQsw5xYlgDd3MY5sAPk4Bt0ncStJ0c7vTH1zdNhpPYs1zdiAQEX5d ADGRprmPcZcmzTFknp2Q6wQqRQUxP3ApMcqyvyTrW9CaeiZM3K6//hLIKDTrU6dQot11 wMYgH0HQT2EVifCTE7A6iOARXsS4xDWAZjN4dKFNVJ3PTAltwpRw+mijq4KQnrg6hobT SYdph3etcLBLJurweH3bkkQeLEytYyGQrV193DqIjHctwzFEN9vtUCJLB80wf8cDeZkg HEdIW5Q49X12GDImu1DYpm7l4/GUkoFMeaaAUOy4Y6Pb7kdb5TmgNCUeFHLTis6NDtS5 QT7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=F9K9bgHxasb0CenAEf+0idBva4OFL5T9xQuTGrzmqwM=; b=KZLz3aevj45j892JSQWJUmsdZ4kbMXV0tZn93TKp9LWpKC6kMyDSMMrfm5lIUrwxa/ hkeCyJCsjGmWbYw5dg8WHrqyF6it8L+nF0DGze7QTV4RriebYVCx5YZheqsS/4JmreLG cB/qcogt3sWPPRMnMxskfVzcnZVyEsuXJra+Z/VloJ4CaX5Vw02Auu2KZ/DI3+sJuwn9 fTv8tK6YfFNajRUQ75sJQgNqlIozcNdxsXfL/EHo5A+oFBSgwaOWiklXTJya8S1gI3el KVJ4GRANP86VoTFtl7ffOyea4aoDq221ioBKeIJ8JEQKg5ZFcS0Wd62BamjWzQjKvyia 2tQQ== X-Gm-Message-State: ALoCoQk/S0nGvSO8aSibzBlqgvCmW3bJk/s3mvO/M20xaiyY/jRrVrsHCdpJ15MWak0RhmZ/57lCZliTS8+E6ypSbxOHeLZrcdW/w1HtCLr6u6Q0hJMQn9Ro7QUdzQ0vmP7Gw1BP379l3lLUzd4BLwa2CCHkvWcsmb84/MbMfmfMomBmjRQZ227v+/6oSSNCCVWUg55PWddK MIME-Version: 1.0 X-Received: by 10.50.134.162 with SMTP id pl2mr371607igb.55.1375993987084; Thu, 08 Aug 2013 13:33:07 -0700 (PDT) Received: by 10.64.240.71 with HTTP; Thu, 8 Aug 2013 13:33:06 -0700 (PDT) In-Reply-To: <520214F7.8020308@mozilla.org> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520214F7.8020308@mozilla.org> Date: Thu, 8 Aug 2013 13:33:06 -0700 Message-ID: From: Chris Palmer To: Gervase Markham Content-Type: text/plain; charset=UTF-8 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 08 Aug 2013 20:33:10 -0000 On Wed, Aug 7, 2013 at 2:35 AM, Gervase Markham wrote: > Surely it would also significantly reduce flexibility? > > At the moment, I can pin to a particular leaf, or a particular > intermediate, or a particular root, or to a set of any of the above. I > can decide where in the chain to pin depending on my analysis of the > cost/benefit. If we instead pinned to CA names, I would lose that > flexibility. Wouldn't I? No, we could allow people to pin to either SPKIs or trust anchor set names or any combination of the two. I don't think anyone has said that it should be trust anchor set names *only*. From ynir@checkpoint.com Thu Aug 8 13:42:14 2013 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 DF86321F99F4 for ; Thu, 8 Aug 2013 13:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.516 X-Spam-Level: X-Spam-Status: No, score=-10.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpFvpixnEqkc for ; Thu, 8 Aug 2013 13:42:10 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9058F21F9AA2 for ; Thu, 8 Aug 2013 13:42:06 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r78Kg3is032673; Thu, 8 Aug 2013 23:42:03 +0300 X-CheckPoint: {5204029B-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Thu, 8 Aug 2013 23:42:02 +0300 From: Yoav Nir To: Tobias Gondrom Thread-Topic: [websec] #58: Should we pin only SPKI, or also names Thread-Index: AQHOjHagv3/BmvZ4wU6WrbkIw+Bd/ZmAXZOAgAADk4CAAHu6gIAIRDGAgAA0tQCAAAIEgIAAAsgAgAACowCAAAVKAIAAXsaAgADFHACAARdCAIAABpsA Date: Thu, 8 Aug 2013 20:42:01 +0000 Message-ID: <2B676EE1-AF70-4905-B184-0CABEFCB7C71@checkpoint.com> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520214F7.8020308@mozilla.org> <52021982.8030108@mozilla.org> <5203FD0E.40506@gondrom.org> In-Reply-To: <5203FD0E.40506@gondrom.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.237] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 110bf6728cbfd39ba743272322996ff0fd7e6b8ec1 Content-Type: text/plain; charset="us-ascii" Content-ID: <3E036B943E024843A5105535BE59323A@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 08 Aug 2013 20:42:15 -0000 On Aug 8, 2013, at 11:18 PM, Tobias Gondrom wrote: > Hi, >=20 > >=20 > On 08/08/13 04:38, Trevor Perrin wrote: >> On Wed, Aug 7, 2013 at 8:53 AM, Yoav Nir wrote: >>> On Aug 7, 2013, at 1:14 PM, Trevor Perrin wrote: >>>> Only CAs which had "opted-in" and provided the requisite info to >>>> browsers would be in the table. >>> I'm only wondering where I get a copy of that table and who maintains i= t. >> CAs and Browsers would have to work that out. I don't know what their >> preferred coordination method would be. >>=20 >=20 > Hm, I did expect we could do the name pinning - if we want to do it - > without additional coordination at all for this. If you pin to the name > in the cert, this would only allow certs from this CA to be trusted for > this specific domain. As in the repository of the browsers as it is > today already. What did I miss here? If you go to https://www.iana.org, you get the following certificate chain: - *.iana.org - Go Daddy Secure Certification Authority - Go Daddy Class 2 Certification Authority So without any registry, you can pin to "Go Daddy Class 2 Certification Aut= hority". But the next time IANA needs to get a certificate (August 2016), e= ven if they get it from Go Daddy, they might get it from the other root CA = ("Go Daddy Root Certificate Authority - G2"), which signs with SHA-256, and= who knows, by then they might have a new one, perhaps with ECDSA. As a cus= tomer, you talk to a vendor. Most customers don't know which TA is actually= going to be used. In some cases (Symantec) there are very many of them. Someone needs to map "Symantec" to a list of pins, and IMO that someone is = neither the IETF nor IANA. Yoav From palmer@google.com Thu Aug 8 13:45:06 2013 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 C3CA111E821A for ; Thu, 8 Aug 2013 13:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Om8+DwaAn4Gv for ; Thu, 8 Aug 2013 13:45:06 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 4D50E11E8104 for ; Thu, 8 Aug 2013 13:45:06 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id tp5so2807677ieb.27 for ; Thu, 08 Aug 2013 13:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3cR06KSI1iMWjNFUawWMHeB/+y6aSowskWUvDPH6o4E=; b=NHQqaOlcfIlMR7uU6o/Sahz1kJaC5WPCTgvNOfT3XHy8ZWW3+9LtobMAQ+ycl9a9cI /mhuoEjhAihG12LYsmKeeVPiqfEW7wSlcElFXTFEZ7JACBnfTw7AD1fN++f3PT8BFsBL xGWNYFsyN5qeETpv8+ANBE+fMzcFtiA5PHbFpxdDDX2RyNG/4PTDtBHu9gaZvPJEd4d6 M05q85gzZmlW9aobYUMIwbD9g9yTzvqFXYCf9n1iCatmZboZ8Wwgg69iVYZCaCuO369F F7HTP8kdovrHLxK5s79R521P4p1iK6Yn5U6MuFP2Fb/CfqUnXrIlseknH0+LONIM8FN5 CtVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3cR06KSI1iMWjNFUawWMHeB/+y6aSowskWUvDPH6o4E=; b=Qfzx1VPJ+FM3Vt7xe8ZCP3oZCpDLjMLdw24nyW1/bbr29xmmcec3P5NrlUXzOQCZ/W Hu1KyzCdSXsULOVsM2MKvK0ydQGTDqIlEgg2iBuiySD+MmY2QpHXKmomBxde20isXevr gBIUhXhPC9S//TSCi2Km3up+zWw2Ym42lHWFsZseiV1ZU31tW52MjPwbPwhBHNKhGinJ pT2a2SWNGStuqarX9w43a4hDccufax/eqIUv4HTug6jTzV0m4kSuI0tF2s10cSsDPkFg P1lC6RIwz0XLHykNsJu4jxqB6/6/Sg+5HjTK3/3SRcCtZgfXVeuqrAVo4SdGaH0eSRfY mijg== X-Gm-Message-State: ALoCoQm8p+WpPoTDo89VETGFweqy0DtHzJYofe0gn/k9mNePAMLd/TcDrdddDM53sRyo2HH0QgRDCQSEc025fG9JoMZBe1OoCQRpq7mG4kmiD16zfmzDhXkgpy5+hkXd3Xdh/FDzHPKG0LogTNZFXcBMf7QNiI6JSc92Jk5FXnlx5SFcVAIdlaXf6wfrNcsJHBz75YeKKJ3X MIME-Version: 1.0 X-Received: by 10.43.19.200 with SMTP id ql8mr2979828icb.72.1375994705749; Thu, 08 Aug 2013 13:45:05 -0700 (PDT) Received: by 10.64.240.71 with HTTP; Thu, 8 Aug 2013 13:45:05 -0700 (PDT) In-Reply-To: <520225B3.5040701@mozilla.org> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520214F7.8020308@mozilla.org> <52021982.8030108@mozilla.org> <520225B3.5040701@mozilla.org> Date: Thu, 8 Aug 2013 13:45:05 -0700 Message-ID: From: Chris Palmer To: Gervase Markham Content-Type: text/plain; charset=UTF-8 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 08 Aug 2013 20:45:06 -0000 On Wed, Aug 7, 2013 at 3:47 AM, Gervase Markham wrote: >> When a pinned CA wants to introduce a new root, it would need to >> update the mapping and wait for the update to propagate before using >> the new root to sign certs. > > Right - but users who were trusting "FooCA" would now be trusting a root > they didn't know they were trusting. The site operator had decided to trust FooCA to manage its operations well and to issue certs well. If FooCA sets up a new root, that need not change the operator's trust calculation. The explicit point of this trust anchor set name mechanism is to allow site operators to not care about the specific signing certificates FooCA uses. You seem to be postulating a hypothetical site operator who wants to trust FooCA generally, yet also wants to know about and trust only particular issuing certificates that FooCA uses. That hypothetical site operator sounds confused, to me: "Don't bother me with all these details; just tell me everything." > What happens if two CAs merge, and the acquiring CA wants to have all > the roots of the acquired CA now under its brand? Same thing. The site operator has chosen to trust FooCA. They can trust FooCA to merge with only top-notch CAs (running their business operations well), and continue pinning to the trust anchor set name "FooCA". Or the operator can decide they hate the new merged business entity, and switch to BarCA. Hopefully, they set a backup pin, possibly to BarCA, and then they can do the switch quite quickly. (They'll want a new backup pin, say QuuxCA, or a specific SPKI, or whatever.) > My concern is that this is an abstraction to make things work for people > who don't want to think too hard about PKI, but that the abstraction is > leaky, and will result in the violation of assumptions. I haven't spent > too much time thinking about this and I've already thought of a few. That's how abstractions are: The leakiness is a feature. If it weren't leaky, it wouldn't be an abstraction. That's why we would offer pinning to both trust anchor set names and specific SPKIs. From palmer@google.com Thu Aug 8 13:57:49 2013 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 4DEC321F9CC0 for ; Thu, 8 Aug 2013 13:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ms7yBdYLBf77 for ; Thu, 8 Aug 2013 13:57:48 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 54AB021F99F3 for ; Thu, 8 Aug 2013 13:57:48 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id qd12so2779842ieb.14 for ; Thu, 08 Aug 2013 13:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2ewwkhbqS/scETtZ26ZpmTK8s0lPT1dPeqbfYbavAu4=; b=kW8jj9U6i9uQz+DxmZPbuYl/xmkqTD9c7k2dFkzHW1mvVaBkWApxCpNHdfwOswpYrF ba7cwTUh97qo3c0XQBLacGVoydk5t3/+pqVP3oJcOwANajS93m0Li/znX1kWeAT4RbTB HrH85kt+pkpTaTF5jBMNrDpl+1Q4KIKVq/FDW5rKrSDdaoRuJZjUOVurWRJjcBk14OpT /86mDyfM7cwoEJy/CJIs9k5R8QtdKRQZcjc3+2ao02ohmHkq6uB1sKlob+XgZHiUwz9N Lruo9UP00Dv7DUS4Fj1vq0vw3t2Fd3De7z/u2b4FumqQbrDotyPG7vUY7gx9qtmA2vOZ UvWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2ewwkhbqS/scETtZ26ZpmTK8s0lPT1dPeqbfYbavAu4=; b=dErCC2aszGT3uR0cD8jcelO2Qu72VqSTgSQInHaUxlA+lTEQF0XvJdMel59j1c02PJ 5Vzzfwn8hbXXyJTAkvb7GakFLuWXblw8Sl48vpjanQ44eBs0giuREHJkEMgPo5nvqyFz j3sZVxEbGYnaMtEr0G34o/RxsTWUldflCslNEIbtlB/T+MMdQyTadWGC1s4XPEPDW7K/ wDEzlNeTvfVZX8qYmFsjLuzXADybfqYjbmZVlkLG5Txmnkt3Ku7d3t94OaiAjiSjTIv0 d2fk8b25pDZu97v7sEwAlROC6zZJam1Kv2QpQorLkg7j+HyvPVeSK2H6Jw96YWwu2UB1 6s5Q== X-Gm-Message-State: ALoCoQmgyH4JfxKjAqKU2nzwh2DFEPUqbTLqdDw6PwrHw6wP5+X7p7ypUuMOmJNyZYiUwxWLmZrK9prMud8Z9aCJiNZ5q3QXBE6NbXNJhEZHIlxFMmWkbhG/AQ5N+8wDqF1fDVara87gx3XE1AvA63WGooP8kFBJfanRrmTI8ZEwu3RCy2LEsfpDf0lRhjRKoJkPAcuKOyS7 MIME-Version: 1.0 X-Received: by 10.50.101.16 with SMTP id fc16mr438140igb.49.1375995467613; Thu, 08 Aug 2013 13:57:47 -0700 (PDT) Received: by 10.64.240.71 with HTTP; Thu, 8 Aug 2013 13:57:47 -0700 (PDT) In-Reply-To: <2B676EE1-AF70-4905-B184-0CABEFCB7C71@checkpoint.com> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520214F7.8020308@mozilla.org> <52021982.8030108@mozilla.org> <5203FD0E.40506@gondrom.org> <2B676EE1-AF70-4905-B184-0CABEFCB7C71@checkpoint.com> Date: Thu, 8 Aug 2013 13:57:47 -0700 Message-ID: From: Chris Palmer To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 08 Aug 2013 20:57:49 -0000 On Thu, Aug 8, 2013 at 1:42 PM, Yoav Nir wrote: > If you go to https://www.iana.org, you get the following certificate chai= n: > - *.iana.org > - Go Daddy Secure Certification Authority > - Go Daddy Class 2 Certification Authority > > So without any registry, you can pin to "Go Daddy Class 2 Certification A= uthority". But the next time IANA needs to get a certificate (August 2016),= even if they get it from Go Daddy, they might get it from the other root C= A ("Go Daddy Root Certificate Authority - G2"), which signs with SHA-256, a= nd who knows, by then they might have a new one, perhaps with ECDSA. As a c= ustomer, you talk to a vendor. Most customers don't know which TA is actual= ly going to be used. In some cases (Symantec) there are very many of them. > > Someone needs to map "Symantec" to a list of pins, and IMO that someone i= s neither the IETF nor IANA. Insane idea (yes, I know it is insane): What if we chose not to have a registry, and let people use substrings of issuer certificate CNs/OUs/whatevers as trust anchor set names? Obvious problems: * character set encoding in the HTTP header vs. in the X.509 certificate: Welcome To Fun-Land, Where Fun Is Not Very Fun(TM) * silly substrings, like "Go" matching both "...Go Daddy..." and "...Google Internet Authority..." and "...Evil Bad People (Goats)..." * substitution characters: should "Securite" match "...S=C3=A9curit=C3=A9 R= =C3=A9seau..." ? I'm sure we can all think of more problems... From ynir@checkpoint.com Thu Aug 8 14:08:51 2013 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 DDCC321E8089 for ; Thu, 8 Aug 2013 14:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.518 X-Spam-Level: X-Spam-Status: No, score=-10.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhpDlpv7wFoO for ; Thu, 8 Aug 2013 14:08:46 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id ED06621F9D4F for ; Thu, 8 Aug 2013 14:08:26 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r78L84L3010866; Fri, 9 Aug 2013 00:08:04 +0300 X-CheckPoint: {520408B4-9-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Fri, 9 Aug 2013 00:08:03 +0300 From: Yoav Nir To: Chris Palmer Thread-Topic: [websec] #58: Should we pin only SPKI, or also names Thread-Index: AQHOjHagv3/BmvZ4wU6WrbkIw+Bd/ZmAXZOAgAADk4CAAHu6gIAIRDGAgAA0tQCAAAIEgIAAAsgAgAACowCAAAVKAIAAXsaAgADFHACAARdCAIAABpsAgAAEaYCAAALdAA== Date: Thu, 8 Aug 2013 21:08:03 +0000 Message-ID: References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520214F7.8020308@mozilla.org> <52021982.8030108@mozilla.org> <5203FD0E.40506@gondrom.org> <2B676EE1-AF70-4905-B184-0CABEFCB7C71@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.237] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11eab6979cfda638275ef7dab90af920757f64435a Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 08 Aug 2013 21:08:52 -0000 On Aug 8, 2013, at 11:57 PM, Chris Palmer wrote: > On Thu, Aug 8, 2013 at 1:42 PM, Yoav Nir wrote: >=20 >> If you go to https://www.iana.org, you get the following certificate cha= in: >> - *.iana.org >> - Go Daddy Secure Certification Authority >> - Go Daddy Class 2 Certification Authority >>=20 >> So without any registry, you can pin to "Go Daddy Class 2 Certification = Authority". But the next time IANA needs to get a certificate (August 2016)= , even if they get it from Go Daddy, they might get it from the other root = CA ("Go Daddy Root Certificate Authority - G2"), which signs with SHA-256, = and who knows, by then they might have a new one, perhaps with ECDSA. As a = customer, you talk to a vendor. Most customers don't know which TA is actua= lly going to be used. In some cases (Symantec) there are very many of them. >>=20 >> Someone needs to map "Symantec" to a list of pins, and IMO that someone = is neither the IETF nor IANA. >=20 > Insane idea (yes, I know it is insane): What if we chose not to have a > registry, and let people use substrings of issuer certificate > CNs/OUs/whatevers as trust anchor set names? Substring??? RegExp!! :-) > Obvious problems: >=20 > * character set encoding in the HTTP header vs. in the X.509 > certificate: Welcome To Fun-Land, Where Fun Is Not Very Fun(TM) > * silly substrings, like "Go" matching both "...Go Daddy..." and > "...Google Internet Authority..." and "...Evil Bad People (Goats)..." > * substitution characters: should "Securite" match "...S=E9curit=E9 R=E9s= eau..." ? >=20 > I'm sure we can all think of more problems=85 Sure. Symantec has done a lot of mergers and acquisitions, including of Verisign,= which also did its share of mergers and acquisitions. So that now, Symante= c has root CAs with brand names Symantec, Verisign, Thawte, and probably se= veral others that I have forgotten. The chances of misconfiguration and bri= cking yourself with a new certificate are rather high. Yoav From palmer@google.com Thu Aug 8 14:18:08 2013 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 4C14A11E8237 for ; Thu, 8 Aug 2013 14:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAg9EVgCgqOp for ; Thu, 8 Aug 2013 14:18:07 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id BD24A11E822B for ; Thu, 8 Aug 2013 14:18:07 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 17so2865255iea.17 for ; Thu, 08 Aug 2013 14:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0IYPryfpBqe61vAJMcHncLJV8LcdxjEnuNo0Ocg7P6c=; b=ccdc5OhHo0s58na7EacxRTzzdCVzQmg9IWAkop9S7RRkA3efJS47LGRAF1/jD6RlE8 qWRgx8EeMZiwauPIi0VKG1BlSpyygr7RDuj/nyBhx78c7zRHj6CP0dFBk4YIcuIbotPo 0NcePbtTyW4GNRQKEkwppQQmzba7ET8qmSMgoTPCmNKHcuhrJ8SPFfnHaqfoZgPhxa9I mvNHvbEfNmnKx97ttyeiT5gh2d0mEA/mtbPpsAdvbrkJFpucE85VuWCrZg9bvPfDbKA0 CATWp/6swElSTWWB/kydnj+enL/BS+xqNVc3/z0+pAyAwJaEFQTHMqu9sHSCcvHOS1bW x1SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0IYPryfpBqe61vAJMcHncLJV8LcdxjEnuNo0Ocg7P6c=; b=UQFkQ+/aqXdgQIDIw24CYs3No6LC3pCqvYVZ0AYhnOrQbZBLeH+c6QqO3893vs8BW4 yDrXh6UwQ1Z/1ql8U5xqWCAZ+wFQ7tNI2ieEoBqJ5a5AJMiniF/y61qd8C2Ocm5nWB+h YFqBCsGUJisxcligRdOFEJBkL4UnDBFYkqQEGElEYkbPSUWSleRqCC5IVtHKt/5dlCWU m/eJl3CmH94tL1B69n/9xn59JQSp9o7QO//7WHUCofcxPh6xr6KCQTHTYPgGOu8GuY8h 4plVrhlH87wLgA+UVB9PjomQuCPR4f+9FMGp9JD0OF6Wsn3qpECBBKRcQvp0K3CDq1yR Re5g== X-Gm-Message-State: ALoCoQl9JI6wATELa7LwMKOUSK+Pmqvw0/e41ApyRSMpEuLymDYBtK6iFNPtJkiGEse4OCsrF4Q+m+MFnZoN9kjU/QnLxNiCu5qkEvV2o/SeT8mdzczVx/qcs3wE5hPh4LP15UYQbs98yud3yj/CQSUDhR37q1TGEBA+WprkkdlzxO58IICMdGQ9z0Hym5NpW93TASw6XnGp MIME-Version: 1.0 X-Received: by 10.43.19.200 with SMTP id ql8mr3039483icb.72.1375996687318; Thu, 08 Aug 2013 14:18:07 -0700 (PDT) Received: by 10.64.240.71 with HTTP; Thu, 8 Aug 2013 14:18:07 -0700 (PDT) In-Reply-To: References: <4CF90F65-62CE-4AE0-9113-932F93A98782@mnot.net> Date: Thu, 8 Aug 2013 14:18:07 -0700 Message-ID: From: Chris Palmer To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Cc: Mark Nottingham , "" Subject: Re: [websec] Well-known URIs 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, 08 Aug 2013 21:18:08 -0000 On Thu, Aug 8, 2013 at 1:27 PM, Yoav Nir wrote: >> Can you say clearly what else we should stuff into the W-K URI for >> HPKP? What other working groups and standards bodies are we going to >> have to reach consensus with? > > The answer to those questions is "nothing" and "none". Sounds good to me. > let's assume the format is JSON, we could call the resource https://www.example.com/.well-known/TransportSecurity.json , and it could be formatted like this: > { > "HPKP": { > "max_age": 2592000, > "include_subdomains": "false", > "pins": [ > { > "alg": "sha1" > "hash": "aQWqfl0MQRwcM+3uffZ08Rttods=" > }, > { > "alg": "sha256" > "hash": "Lbl5D9eR4PLiaOUSeO6sue2QrSvpB31F4mte/4D75xM=" > }, > ] > } > } > > Then if someone wants to add HSTS into this, they're welcome to it, but they'll need their own document to do it. I was thinking maybe we could get rid of max_age and have the max age be simply the lifetime of the resource as defined by the Cache-Control header. Maybe that's a bad idea, I don't know. From tobias.gondrom@gondrom.org Thu Aug 8 14:36:14 2013 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 1A80A21F9D3B for ; Thu, 8 Aug 2013 14:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eo8MijC0fexi for ; Thu, 8 Aug 2013 14:36:07 -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 C1FC811E822D for ; Thu, 8 Aug 2013 14:36:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=uzcwM0VZGytokFsEnXrUYQSDyVTOz1/n5kNftwT6VEtxGLXDusPTbLmWa9oE5f6vHLu3g3I57lvxzEZGWxlo6wUPR+9aUiYp1JkrUcauYqSX0S6yfZTokak3wVscvmtc; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 13853 invoked from network); 8 Aug 2013 23:36:05 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.64?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 8 Aug 2013 23:36:05 +0200 Message-ID: <52040F44.3040606@gondrom.org> Date: Thu, 08 Aug 2013 22:36:04 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: ynir@checkpoint.com References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520214F7.8020308@mozilla.org> <52021982.8030108@mozilla.org> <5203FD0E.40506@gondrom.org> <2B676EE1-AF70-4905-B184-0CABEFCB7C71@checkpoint.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------070903010207070504090709" Cc: websec@ietf.org Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 08 Aug 2013 21:36:16 -0000 This is a multi-part message in MIME format. --------------070903010207070504090709 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 08/08/13 22:08, Yoav Nir wrote: > On Aug 8, 2013, at 11:57 PM, Chris Palmer wrote: > >> On Thu, Aug 8, 2013 at 1:42 PM, Yoav Nir wrote: >> >>> If you go to https://www.iana.org, you get the following certificate chain: >>> - *.iana.org >>> - Go Daddy Secure Certification Authority >>> - Go Daddy Class 2 Certification Authority >>> >>> So without any registry, you can pin to "Go Daddy Class 2 Certification Authority". But the next time IANA needs to get a certificate (August 2016), even if they get it from Go Daddy, they might get it from the other root CA ("Go Daddy Root Certificate Authority - G2"), which signs with SHA-256, and who knows, by then they might have a new one, perhaps with ECDSA. As a customer, you talk to a vendor. Most customers don't know which TA is actually going to be used. In some cases (Symantec) there are very many of them. >>> >>> Someone needs to map "Symantec" to a list of pins, and IMO that someone is neither the IETF nor IANA. >> Insane idea (yes, I know it is insane): What if we chose not to have a >> registry, and let people use substrings of issuer certificate >> CNs/OUs/whatevers as trust anchor set names? > Substring??? RegExp!! :-) > >> Obvious problems: >> >> * character set encoding in the HTTP header vs. in the X.509 >> certificate: Welcome To Fun-Land, Where Fun Is Not Very Fun(TM) >> * silly substrings, like "Go" matching both "...Go Daddy..." and >> "...Google Internet Authority..." and "...Evil Bad People (Goats)..." >> * substitution characters: should "Securite" match "...Sécurité Réseau..." ? >> >> I'm sure we can all think of more problems… > Sure. > > Symantec has done a lot of mergers and acquisitions, including of Verisign, which also did its share of mergers and acquisitions. So that now, Symantec has root CAs with brand names Symantec, Verisign, Thawte, and probably several others that I have forgotten. The chances of misconfiguration and bricking yourself with a new certificate are rather high. > > Yoav > Actually, I think the chances of bricking yourself are reasonably low/ok. 1. Consider that the CA must have the responsibility to inform the website about any name changes of its organisation. 2. the name change of the cert only hits you when you get a new cert from the organisation, as the name in your existing cert is still the old one (old signing CA). 3. Before adding a new individual cert you need to phase out the old, by using the dual pin (or dual name). So I think the technical requirements are reasonably low to make this work. And if people don't feel they are capable to do so, they can stay with the normal pin to individual certs. Just my 5cents, Tobias --------------070903010207070504090709 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 08/08/13 22:08, Yoav Nir wrote:
On Aug 8, 2013, at 11:57 PM, Chris Palmer <palmer@google.com> wrote:


On Thu, Aug 8, 2013 at 1:42 PM, Yoav Nir <ynir@checkpoint.com> wrote:


If you go to https://www.iana.org, you get the following certificate chain:
- *.iana.org
- Go Daddy Secure Certification Authority
- Go Daddy Class 2 Certification Authority

So without any registry, you can pin to "Go Daddy Class 2 Certification Authority". But the next time IANA needs to get a certificate (August 2016), even if they get it from Go Daddy, they might get it from the other root CA ("Go Daddy Root Certificate Authority - G2"), which signs with SHA-256, and who knows, by then they might have a new one, perhaps with ECDSA. As a customer, you talk to a vendor. Most customers don't know which TA is actually going to be used. In some cases (Symantec) there are very many of them.

Someone needs to map "Symantec" to a list of pins, and IMO that someone is neither the IETF nor IANA.

Insane idea (yes, I know it is insane): What if we chose not to have a
registry, and let people use substrings of issuer certificate
CNs/OUs/whatevers as trust anchor set names?

Substring???  RegExp!!  :-)


Obvious problems:

* character set encoding in the HTTP header vs. in the X.509
certificate: Welcome To Fun-Land, Where Fun Is Not Very Fun(TM)
* silly substrings, like "Go" matching both "...Go Daddy..." and
"...Google Internet Authority..." and "...Evil Bad People (Goats)..."
* substitution characters: should "Securite" match "...Sécurité Réseau..." ?

I'm sure we can all think of more problems…

Sure.

Symantec has done a lot of mergers and acquisitions, including of Verisign, which also did its share of mergers and acquisitions. So that now, Symantec has root CAs with brand names Symantec, Verisign, Thawte, and probably several others that I have forgotten. The chances of misconfiguration and bricking yourself with a new certificate are rather high.

Yoav

<no hats>

Actually, I think the chances of bricking yourself are reasonably low/ok.

1. Consider that the CA must have the responsibility to inform the website about any name changes of its organisation.
2. the name change of the cert only hits you when you get a new cert from the organisation, as the name in your existing cert is still the old one (old signing CA).
3. Before adding a new individual cert you need to phase out the old, by using the dual pin (or dual name).

So I think the technical requirements are reasonably low to make this work. And if people don't feel they are capable to do so, they can stay with the normal pin to individual certs.

Just my 5cents, Tobias




 --------------070903010207070504090709-- From ynir@checkpoint.com Thu Aug 8 14:45:35 2013 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 6D99F11E8238 for ; Thu, 8 Aug 2013 14:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.519 X-Spam-Level: X-Spam-Status: No, score=-10.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsO4RXNOrLi3 for ; Thu, 8 Aug 2013 14:45:29 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4063411E8236 for ; Thu, 8 Aug 2013 14:45:28 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r78LjPYf024459; Fri, 9 Aug 2013 00:45:25 +0300 X-CheckPoint: {52041174-F-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Fri, 9 Aug 2013 00:45:24 +0300 From: Yoav Nir To: Chris Palmer Thread-Topic: [websec] Well-known URIs Thread-Index: AQHOlFgB2fNLbEWVFkSgl8GkYD3KkJmLgOoAgAAPfoCAAA4qgIAAB56A Date: Thu, 8 Aug 2013 21:45:23 +0000 Message-ID: <681B3865-0333-482F-AE35-B3A460B08664@checkpoint.com> References: <4CF90F65-62CE-4AE0-9113-932F93A98782@mnot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.237] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11c5b12eda50469c83cfaf479e96bf7ece4b6a6f9a Content-Type: text/plain; charset="us-ascii" Content-ID: <79007AB2DAE476459907F1680DE420BD@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] Well-known URIs 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, 08 Aug 2013 21:45:35 -0000 On Aug 9, 2013, at 12:18 AM, Chris Palmer wrote: >>=20 >=20 > I was thinking maybe we could get rid of max_age and have the max age > be simply the lifetime of the resource as defined by the Cache-Control > header. Maybe that's a bad idea, I don't know. [no hats] I don't like it. Especially if we keep it extensible, and something else (H= STS?) might need a different value. Besides, adding this resource to a serv= er is easy - just place a file in the right directory. Changing the Cache-c= ontrol properties of one particular resource on the server is harder if at = all possible - it depends on the server software. Yoav From gerv@mozilla.org Fri Aug 9 02:52:34 2013 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 8475D21F84A8 for ; Fri, 9 Aug 2013 02:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1EdOL52xQBj for ; Fri, 9 Aug 2013 02:52:28 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0DF21F9B07 for ; Fri, 9 Aug 2013 02:52:15 -0700 (PDT) Received: from [192.168.0.22] (cpc2-enfi16-2-0-cust610.hari.cable.virginmedia.com [94.170.82.99]) (Authenticated sender: gerv@mozilla.org) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 48ABBF20DC; Fri, 9 Aug 2013 02:52:13 -0700 (PDT) Message-ID: <5204BBCC.1060005@mozilla.org> Date: Fri, 09 Aug 2013 10:52:12 +0100 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Chris Palmer References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520214F7.8020308@mozilla.org> <52021982.8030108@mozilla.org> <5203FD0E.40506@gondrom.org> <2B676EE1-AF70-4905-B184-0CABEFCB7C71@checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 09 Aug 2013 09:52:34 -0000 On 08/08/13 21:57, Chris Palmer wrote: > Insane idea (yes, I know it is insane): What if we chose not to have a > registry, and let people use substrings of issuer certificate > CNs/OUs/whatevers as trust anchor set names? That is a truly insane idea. Let's pin to "DigiCert". That'll be OK, right? Er, no: https://blog.mozilla.org/security/2011/11/03/revoking-trust-in-digicert-sdn-bhd-intermediate-certificate-authority/ Gerv From ietf-secretariat-reply@ietf.org Thu Aug 8 14:26:01 2013 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 6686A21F9E3B for ; Thu, 8 Aug 2013 14:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hF4dZDCm+FDB; Thu, 8 Aug 2013 14:26:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA94911E822E; Thu, 8 Aug 2013 14:25:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: websec-chairs@tools.ietf.org, draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130808212557.20972.97523.idtracker@ietfa.amsl.com> Date: Thu, 08 Aug 2013 14:25:57 -0700 From: IETF Secretariat X-Mailman-Approved-At: Fri, 09 Aug 2013 04:27:12 -0700 Subject: [websec] ID Tracker State Update Notice: 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, 08 Aug 2013 21:26:01 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-o= ptions/ From mnot@mnot.net Fri Aug 9 03:02:13 2013 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 2A41221F96B6 for ; Fri, 9 Aug 2013 03:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhcnJqy-6t9d for ; Fri, 9 Aug 2013 03:02:08 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id E9CA921F9633 for ; Fri, 9 Aug 2013 03:02:07 -0700 (PDT) Received: from [10.177.76.220] (unknown [115.160.170.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4E1D850A88; Fri, 9 Aug 2013 06:02:02 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Mark Nottingham In-Reply-To: Date: Fri, 9 Aug 2013 18:01:51 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CF90F65-62CE-4AE0-9113-932F93A98782@mnot.net> To: Chris Palmer X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Fri, 09 Aug 2013 04:27:12 -0700 Cc: "" Subject: Re: [websec] Well-known URIs 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, 09 Aug 2013 10:02:13 -0000 On 09/08/2013, at 3:31 AM, Chris Palmer wrote: > On Thu, Aug 8, 2013 at 5:35 AM, Mark Nottingham wrote: >=20 >> 1. Well-known URIs are designed for cases where the client wants to = get a bunch of *related* data together; as such, a general framework is = encouraged, as long as the use cases are similar. >>=20 >> This is why I don't like hostmeta; it's a bucket for anything you = want to throw in there, which means that over time, the client will be = getting a lot of information they don't want, which will necessitate a = query language, which is just nasty overkill. At the other end of the = spectrum, having a single-use well-known URI in the critical path (or = even not) for a browser is similarly Not A Good Idea. >=20 > Can you say clearly what else we should stuff into the W-K URI for > HPKP? What other working groups and standards bodies are we going to > have to reach consensus with? Um, implementers? >=20 >> 3. Alternatively, if browsers are pre connecting, they could use the = conn to fetch a well-known URI, as long as it was cheap to fetch. That = policy file could even control how aggressively the browser pre-connects = (two birds, one stone=85). >=20 > You just said it should *not* become a catch-all bucket. It's a subtle thing. You want things that tend to be accessed at the = same time, by the same clients; that's the shape of the bucket. They may = or may not be related conceptually; it's all about audience (sort of = like user-centred design). Cheers, -- Mark Nottingham http://www.mnot.net/ From rjsparks@nostrum.com Fri Aug 9 13:47:08 2013 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 6804521F92B7 for ; Fri, 9 Aug 2013 13:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVmdDNhi+nrd for ; Fri, 9 Aug 2013 13:47:07 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 23ADD21F9E22 for ; Fri, 9 Aug 2013 13:40:05 -0700 (PDT) Received: from [10.215.109.7] (mobile-166-147-076-150.mycingular.net [166.147.76.150]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r79Kds7i066864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 9 Aug 2013 15:39:58 -0500 (CDT) (envelope-from rjsparks@nostrum.com) References: <5203F8C2.3060807@nostrum.com> From: Robert Sparks Content-Type: multipart/alternative; boundary=Apple-Mail-EA4C3BB5-E794-48CF-9099-20311524A0DE X-Mailer: iPhone Mail (10B329) Message-Id: <954EE088-8858-4814-9D8A-CCFE31EDC715@nostrum.com> Date: Fri, 9 Aug 2013 15:39:47 -0500 To: "websec@ietf.org" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Received-SPF: pass (shaman.nostrum.com: 166.147.76.150 is authenticated by a trusted mechanism) Subject: [websec] Fwd: Genart LC review: draft-ietf-websec-x-frame-options-07 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, 09 Aug 2013 20:47:08 -0000 --Apple-Mail-EA4C3BB5-E794-48CF-9099-20311524A0DE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Forwarding at Barry's request. Please copy me directly in replies.=20 Sent from my iPhone Begin forwarded message: > From: Robert Sparks > Date: August 8, 2013, 3:00:02 PM CDT > To: General Area Review Team , draft-ietf-websec-x-fram= e-options@tools.ietf.org > Subject: Genart LC review: draft-ietf-websec-x-frame-options-07 >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at >=20 > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-websec-x-frame-options-07 > Reviewer: Robert Sparks > Review Date: 2013-08-08 > IETF LC End Date: 2013-08-12 > IESG Telechat date: 2013-08-15 >=20 > Summary: This draft is basically ready for publication, but has nits that s= hould be fixed before publication. >=20 > This document is intended to act as a informational reference describing w= hat's already deployed, and not to act as a standard for new implementations= to follow. It's obvious that some care has been taken to keep that tone in t= he text, but there are places where it still looks like a proposed standard.= Please make it even more clear who the audience for this document is, and l= ook for places to reinforce that this is documenting what _is_, as opposed t= o trying to influence what should be. >=20 > The introduction of this version of the document does a good job of descri= bing what a clickjack attack is. Appendix B is not really adding to that des= cription. I suggest that the two usecases it call out be reduced to a couple= of sentences in the introduction as examples, and a reference to a more in-= depth treatment of scenarios like them be added for those looking for more i= nformation. Section B.3 is different, and doesn't add to the understanding o= f this document. Again, I suggest pointing to somewhere else that provides a= n in-depth treatment. (Hopefully, that source would discuss the nested frame= issue the security considerations section points out in the context of the t= his specific configuration page). [FRAME-BUSTING] might be enough, but point= ers to something even more rich would certainly be helpful. >=20 > Here are some suggestions in document order: >=20 > In the Abstract, I suggest replace "specification" with either "definition= " as the introduction uses, or with "the syntax and behavior observed in cur= rent deployments". >=20 > The last paragraph of the introduction reads like standards text. Please c= onsider rewriting it with a tone of history and current fact. Perhaps starti= ng with "In existing implementations, ", and replacing the last sentence wit= h something like "The policy this HTTP header declares is enforced by the br= owser implementations documented here". >=20 > Since this is documenting an existing deployed header (not standardizing i= t), it would be useful to comment whether the existing known implementations= allow all the productions of the ABNF described here to be used. For instan= ce, would they all honor X-FRAME-OPTIONS: deny? (While thinking about this, f= ocus on who this document is for.) >=20 > The last sentence of 2.3.1 as written is an attempt to be a standard, and i= s an odd use of 2119. I suggest rewriting it as a warning about what happens= with existing plugins that ignore the policy carrid in the header. That kee= ps the message aligned with documenting what exists. >=20 > The first sentence of 2.3.2 is not adding anything to the document. I sugg= est deleting it. The second sentence is placing an implementation requiremen= t again. Please consider rewriting as an observation of what existing things= do, calling out the ramifications of the ones that behave differently. >=20 > Similarly, the first paragraphs of Section 2.3.2.1 is written to affect ne= w implementation, not document existing implementation. They could be re-tun= ed as above. The third paragraph is good history >=20 > The last sentence of 2.3.2.2 should not say "replace this document" - this= document is informational documentation about existing deployments. CSP1.1 w= on't Obsolete or Replace this document. Rather it should say something like "= it is expected that newer implementations will use it rather than the mechan= isms documented here". >=20 > Nit: s/does support only one/only supports one/ >=20 > Do the known implementations follow the pattern described in 2.3.2.3? Sayi= ng something would help tie this to being information about the known deploy= ment rather than trying to constrain new development. >=20 > Nit: If Appendix B is kept, please expand CSRF (and consider re-pointing t= o a reference) >=20 --Apple-Mail-EA4C3BB5-E794-48CF-9099-20311524A0DE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Forwarding at Barry's request. Please c= opy me directly in replies. 

Sent from my iPhone

B= egin forwarded message:

From:= Robert Sparks <rjsparks@nost= rum.com>
Date: August 8, 2013, 3:00:02 PM CDT
To:= General Area Review Team <gen-art@ie= tf.org>,  draft-ietf-websec-x-frame-options@tools.ietf.org
Sub= ject: Genart LC review: draft-ietf-websec-x-frame-options-07
<= br>
I am the assigned= Gen-ART reviewer for this draft. For background on
Gen-ART,= please see the FAQ at

<http://wiki.tools.ietf.o= rg/area/gen/trac/wiki/GenArtfaq>.

Pl= ease resolve these comments along with any other Last Call commentsyou may receive.

Document: draft-ie= tf-websec-x-frame-options-07
Reviewer: Robert Sparks<= br>Review Date: 2013-08-08
IETF LC End Date: 2013-08-1= 2
IESG Telechat date: 2013-08-15

= Summary: This draft is basically ready for publication, but has nits t= hat should be fixed before publication.

Thi= s document is intended to act as a informational reference describing what's= already deployed, and not to act as a standard for new implementations to f= ollow. It's obvious that some care has been taken to keep that tone in the t= ext, but there are places where it still looks like a proposed standard. Ple= ase make it even more clear who the audience for this document is, and look f= or places to reinforce that this is documenting what _is_, as opposed to try= ing to influence what should be.

The introd= uction of this version of the document does a good job of describing what a c= lickjack attack is. Appendix B is not really adding to that description. I s= uggest that the two usecases it call out be reduced to a couple of sentences= in the introduction as examples, and a reference to a more in-depth treatme= nt of scenarios like them be added for those looking for more information. S= ection B.3 is different, and doesn't add to the understanding of this docume= nt. Again, I suggest pointing to somewhere else that provides an in-depth tr= eatment. (Hopefully, that source would discuss the nested frame issue the se= curity considerations section points out in the context of the this specific= configuration page). [FRAME-BUSTING] might be enough, but pointers to somet= hing even more rich would certainly be helpful.

<= span>Here are some suggestions in document order:
In the Abstract, I suggest replace "specification" with either "defin= ition" as the introduction uses, or with "the syntax and behavior observed i= n current deployments".

The last paragraph o= f the introduction reads like standards text. Please consider rewriting it w= ith a tone of history and current fact. Perhaps starting with "In existing i= mplementations, ", and replacing the last sentence with something like "The p= olicy this HTTP header declares is enforced by the browser implementations d= ocumented here".

Since this is documenting a= n existing deployed header (not standardizing it), it would be useful to com= ment whether the existing known implementations allow all the productions of= the ABNF described here to be used. For instance, would they all honor X-FR= AME-OPTIONS: deny? (While thinking about this, focus on who this document is= for.)

The last sentence of 2.3.1 as writte= n is an attempt to be a standard, and is an odd use of 2119. I suggest rewri= ting it as a warning about what happens with existing plugins that ignore th= e policy carrid in the header. That keeps the message aligned with documenti= ng what exists.

The first sentence of 2.3.2= is not adding anything to the document. I suggest deleting it. The second s= entence is placing an implementation requirement again. Please consider rewr= iting as an observation of what existing things do, calling out the ramifica= tions of the ones that behave differently.

= Similarly, the first paragraphs of Section 2.3.2.1 is written to affect new i= mplementation, not document existing implementation. They could be re-tuned a= s above. The third paragraph is good history

The last sentence of 2.3.2.2 should not say "replace this document" - this= document is informational documentation about existing deployments. CSP1.1 w= on't Obsolete or Replace this document. Rather it should say something like "= it is expected that newer implementations will use it rather than the mechan= isms documented here".

Nit: s/does support o= nly one/only supports one/

Do the known imp= lementations follow the pattern described in 2.3.2.3? Saying something would= help tie this to being information about the known deployment rather than t= rying to constrain new development.

Nit: If= Appendix B is kept, please expand CSRF (and consider re-pointing to a refer= ence)

= --Apple-Mail-EA4C3BB5-E794-48CF-9099-20311524A0DE-- From hallam@gmail.com Sat Aug 10 13:25:16 2013 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 3762711E8187 for ; Sat, 10 Aug 2013 13:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNjIKY26X-zx for ; Sat, 10 Aug 2013 13:25:15 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id AE53B11E810E for ; Sat, 10 Aug 2013 13:18:45 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so4293649wes.26 for ; Sat, 10 Aug 2013 13:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eCrV6U0R1m2LdFUk2nslQZI8SqHCxdSghTfT13KKK4Y=; b=srkz+L/z1gRLK9U7FlAHmR/Hu+/Ix4xHcVbGG+05ngU11wetMhvsTTb4CjXbpdUZZM EhFK20X67SWpIbzTnSrSaPv2Aoxasx646lRa1e+ykbZybOj/Uwhdp9i2qeraAU74tm6r e28wWF4qGcyYusugPf4Gj5z3JUEPPwWuqpHSF4tht/pGtv6rWAyxhERZF8oUB+fF3ID/ SG/qSPuH+nNhH4ChBsoV14ceWk/tYwk/Xhz4AOWtbUN60K+sYrX1DRQVvX2Z9jKh5Opc 3eAK7yCjSWlVlVoRLPjnzVonAN6kFfH1JTUTZLrUqBQ9ViR9fyrREt87hKrcHpGP6e9j GUiw== MIME-Version: 1.0 X-Received: by 10.180.182.229 with SMTP id eh5mr3180053wic.63.1376165920859; Sat, 10 Aug 2013 13:18:40 -0700 (PDT) Received: by 10.194.6.67 with HTTP; Sat, 10 Aug 2013 13:18:40 -0700 (PDT) In-Reply-To: <5201FF3C.3060804@mozilla.org> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <5201FF3C.3060804@mozilla.org> Date: Sat, 10 Aug 2013 21:18:40 +0100 Message-ID: From: Phillip Hallam-Baker To: Gervase Markham Content-Type: multipart/alternative; boundary=089e0163491edd6c5004e39d981e Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 10 Aug 2013 20:25:16 -0000 --089e0163491edd6c5004e39d981e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 7, 2013 at 9:03 AM, Gervase Markham wrote: > On 07/08/13 07:19, Yoav Nir wrote: > > Even if others chime in now and say that they do want this change, I > > think we can't just ask administrators to list random names in > > headers or resources. For example, what string do you use for the > > bunch of trust anchors formerly known as "Verisign"? Do you call it > > "Verisign"? "VERISIGN"? "Symantec"? Are the Thawte public keys > > covered by the "Symantec" label? the "Verisign" label? A wrong > > choice by an administrator (like getting your next certificate from a > > Thawte brand CA and expecting it to be covered by your "Symantec" > > pin) could lead to bricking the site. > > Without expressing an opinion on the question, it's worth noting that > this is already an issue with CAA, albeit that Symantec has to decide a > set of domain names (rather than simple strings) to represent them or > their brands. This was not a particularly difficult exercise for them, > they probably have the most roots and most brands, and it only had to be > done once. > > So I'd suggest that it's not an insuperable obstacle. > > > That is not to say we must not do this, but we must not do this > > without a registry for CA strings. > > Or just require people to use "a domain name I control" rather than a > bare string, like CAA. No need for a registry. > There are two questions here. 1) Should we introduce a level of indirection. i.e. should we only be talking about pinning to bits that are actually present in the certificate chain or should we support something more. 2) If the answer to (1) is to have indirection, who should maintain the registry. The main argument that I am making is that if the answer to (1) is 'yes' then reuse the approach taken in CAA and do not introduce a new registry because we do not want to maintain separate registries for different purposes. The secondary argument is that having established that the CAs are going to have to decide on the domain names and scope etc. issues for CAA, the cost of indirection is lowered. -- Website: http://hallambaker.com/ --089e0163491edd6c5004e39d981e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Aug 7, 2013 at 9:03 AM, Gervase Markham &= lt;gerv@mozilla.org> wrote:
On 07/08/13 07:19, Yoav Ni= r wrote:
> Even if others chime in now and say that they do want this change, I > think we can't just ask administrators to list random names in
> headers or resources. For example, what string do you use for the
> bunch of trust anchors formerly known as "Verisign"? =A0Do y= ou call it
> "Verisign"? =A0"VERISIGN"? "Symantec"? A= re the Thawte public keys
> covered by the "Symantec" label? the "Verisign" la= bel? =A0A wrong
> choice by an administrator (like getting your next certificate from a<= br> > Thawte brand CA and expecting it to be covered by your "Symantec&= quot;
> pin) could lead to bricking the site.

Without expressing an opinion on the question, it's worth noting = that
this is already an issue with CAA, albeit that Symantec has to decide a
set of domain names (rather than simple strings) to represent them or
their brands. This was not a particularly difficult exercise for them,
they probably have the most roots and most brands, and it only had to be done once.

So I'd suggest that it's not an insuperable obstacle.

> That is not to say we must not do this, but we must not do this
> without a registry for CA strings.

Or just require people to use "a domain name I control" rat= her than a
bare string, like CAA. No need for a registry.

There are two questions here.

1) Should we= introduce a level of indirection. i.e. should we only be talking about pin= ning to bits that are actually present in the certificate chain or should w= e support something more.

2) If the answer to (1) is to have indirection, who sho= uld maintain the registry.


The main= argument that I am making is that if the answer to (1) is 'yes' th= en reuse the approach taken in CAA and do not introduce a new registry beca= use we do not want to maintain separate registries for different purposes.= =A0

The secondary argument is that having established that = the CAs are going to have to decide on the domain names and scope etc. issu= es for CAA, the cost of indirection is lowered.
=A0


--
Website: http://hallambaker.com/
--089e0163491edd6c5004e39d981e-- From trevp@trevp.net Sat Aug 10 21:30:55 2013 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 93E8321F9B86 for ; Sat, 10 Aug 2013 21:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-0.810, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_BACKHAIR_23=1, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tn3DDa3q9we2 for ; Sat, 10 Aug 2013 21:30:49 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2C60521F9EEE for ; Sat, 10 Aug 2013 21:25:54 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id t61so4634755wes.31 for ; Sat, 10 Aug 2013 21:25:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=I7vKG8RQeLz9gt3bbQwOUWtGBQY3UlFJxMW9alNI5YI=; b=MVlq9Zrwq5/pVBU2tmsIJwLEDEG1P6dmWoKoVtUsKSpjo0cYkdisJs19l5qJzUbGtK jBDsH4GY3gDheiOU4javhyEis0j2SaJYDvdmiyHXlgv2vV5NDh4FfKQH2oDB+kmCMW6b HI9Q8Mc1b58cRxW1C5NLe5IX3AT3vfzAsgxjqWfrpHXBa0dKHIjtNEpFVvnAAVQ8HaD2 6b3nbkmsDISnWc69SRZl/jYmzSajUl7bj3n5xv+Je6hVIou4FSbqdK4w6cc6l1yx2a3r 2PzD+/BzQ5L+AcRjkpocBbQ9+h7dBBMsNhwKJXnriC3nST44OflslrPzIA/4XSpSAQfa q4vQ== X-Gm-Message-State: ALoCoQkQtn8fyMDGwVfPVOXTYcROpbkk1UwSYX3MxfIJv+QbbrsPnO6pXiBBR8oyLWs4UyD1dZE1 MIME-Version: 1.0 X-Received: by 10.180.10.202 with SMTP id k10mr3580629wib.17.1376195154066; Sat, 10 Aug 2013 21:25:54 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Sat, 10 Aug 2013 21:25:53 -0700 (PDT) X-Originating-IP: [50.37.31.184] In-Reply-To: References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> Date: Sat, 10 Aug 2013 21:25:53 -0700 Message-ID: From: Trevor Perrin To: Chris Palmer Content-Type: text/plain; charset=ISO-8859-1 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 11 Aug 2013 04:30:55 -0000 On Thu, Aug 8, 2013 at 1:26 PM, Chris Palmer wrote: > On Tue, Aug 6, 2013 at 11:19 PM, Yoav Nir wrote: > >> That is not to say we must not do this, but we must not do this without a registry for CA strings. [...] > > With such a registry, I'd support it. Do we need to do this now? Could we just say: - The holder of a domain name is responsible for specifying the SPKIs that it maps to. - How the domain holder communicates this to the UA is out of scope. In the short term CAs and browser vendors could coordinate manually. If this type of pinning becomes popular, more scalable mechanisms can be evolved. These mechanisms might be complex. For example, CAs might publish their key lists somewhere browser vendors could scan for them, and there might be timing rules requiring changes be published X days in advance, and requiring browser vendors to rescan for changes every Y days. But maybe it would be totally different. Maybe we'd have to experiment with multiple mechanisms. And maybe named pinning won't take off, so none of this is necessary. So it seems best to separate this from HPKP, and advance HPKP now in a way that lets us experiment with named pinning. The hard work of building a scaleable system for CA<->key mapping can be postponed until it's necessary and we have a better understanding of requirements. Trevor From tobias.gondrom@gondrom.org Sun Aug 11 04:41:45 2013 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 9449021F98AD for ; Sun, 11 Aug 2013 04:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eh74MzO6QbyX for ; Sun, 11 Aug 2013 04:41:40 -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 C4DA721F9CD9 for ; Sun, 11 Aug 2013 04:34:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=GaW/Ophjn3zql+f1IarTbJbWf2BxxQjjFWrCvVvZYw8ur5zsBk2sqwuXO08x3Fp9V6X/1Tx25gAews7wGT0v272gPJ4yuNTuYJx3NnIDztXQViKtqR/EMbIQYHATmPc9; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 5313 invoked from network); 11 Aug 2013 13:34:24 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.64?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 11 Aug 2013 13:34:24 +0200 Message-ID: <520776C0.9080202@gondrom.org> Date: Sun, 11 Aug 2013 12:34:24 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: websec@ietf.org References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 11 Aug 2013 11:41:45 -0000 Hi all, A small question about pinning to names and uniqueness of "pinned names": Under which conditions could the following attack scenario be a problem and what would we do about it? Domain A has bought a cert from CA-11 with the name "super safe" and pins to the name instead of the cert. CA-11 could be an intermediate for CA-1 with the name "uber super safe". Which names could we pin to? - the intermediate CA-1 and/or CA-11? Now wondering whether the following is a problem: attacker gains control over CA-2 (either through an attack or through government influence) and issues a certificate for an intermediate CA-11' with the name "super safe". CA-11' then signs its certs for Domain A. If we pinned to its name, could an attacker now bypass key-pinning protection by using certs from CA-11'? What am I missing? Under which conditions would this work? Best regards, Tobias From trevp@trevp.net Sun Aug 11 08:59:08 2013 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 3725E21F9EE1 for ; Sun, 11 Aug 2013 08:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D46p-0t8Tf3V for ; Sun, 11 Aug 2013 08:59:02 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0211921F9BF0 for ; Sun, 11 Aug 2013 08:54:00 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id m15so4722165wgh.17 for ; Sun, 11 Aug 2013 08:54:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tOVljYPoBQhZ0+oUkY3RMOhGgs9SNVQ7TFFK7LzbhQ0=; b=GgkVI+DhnMfXPDDkNHVsMB/4FjggiAacZBqWZkGGho6s8ZBSUkI+ANivGEDUIAYNQM IvSrCBMoSWOBFTVuXUG/zz96xalWYB3FEYkikS4pnJZQgI09tD25A5k0Z609yV38MBBl ufNYJbbOWFb1AKGDrQAAuAebx32m5sUSBL/sTUbBBKaXEWNSQ6lCs1sTxVls2aewDigW LbFjgNcz6BqQkbQQ+zobtQI6SsGoTxyP6F6JuG4UAAvLwYaXEC0LO0THyjS7OjZ5+Uu4 VnY24BH3jkVnlN4h7kYdNozmcrCwi+eAEL4OL+SVQ2hsM/w80DANml7HUnn/QjbMwMDj ipLw== X-Gm-Message-State: ALoCoQneytXEkQM6wCV6wJ61Nk9Kfe7XV48WlVbXPwwD6P92J7c32mJc+NmRWDDarqkRXOXCy4lm MIME-Version: 1.0 X-Received: by 10.180.78.133 with SMTP id b5mr4443447wix.17.1376236440125; Sun, 11 Aug 2013 08:54:00 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Sun, 11 Aug 2013 08:54:00 -0700 (PDT) X-Originating-IP: [50.37.31.184] In-Reply-To: <520776C0.9080202@gondrom.org> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520776C0.9080202@gondrom.org> Date: Sun, 11 Aug 2013 08:54:00 -0700 Message-ID: From: Trevor Perrin To: Tobias Gondrom Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 11 Aug 2013 15:59:08 -0000 On Sun, Aug 11, 2013 at 4:34 AM, Tobias Gondrom wrote: > Hi all, > > > > A small question about pinning to names and uniqueness of "pinned names": > Under which conditions could the following attack scenario be a problem > and what would we do about it? > > Domain A has bought a cert from CA-11 with the name "super safe" and > pins to the name instead of the cert. > CA-11 could be an intermediate for CA-1 with the name "uber super safe". > Which names could we pin to? > - the intermediate CA-1 and/or CA-11? > > Now wondering whether the following is a problem: > attacker gains control over CA-2 (either through an attack or through > government influence) and issues a certificate for an intermediate > CA-11' with the name "super safe". Yes, that's a problem. Gerv also brought up the "DigiCert" name collision. So using names as a "layer of indirection" to point to a set of CA-declared keys seems better than trying to pin to names as they appear in certs. Trevor From tobias.gondrom@gondrom.org Sun Aug 11 11:09:45 2013 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 60E4121E805F for ; Sun, 11 Aug 2013 11:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.361 X-Spam-Level: X-Spam-Status: No, score=-95.361 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGGeiPr89lUm for ; Sun, 11 Aug 2013 11:09:40 -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 9368121F9425 for ; Sun, 11 Aug 2013 11:02:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=haqNioFVDVPFRwpjAbc0FWKO1Rp3Kykm+dlefw9n/CmyjLkXeY5Ub8gqIsqtDUe0yGST7wsH+Ed22cL+RHpmxnC8DaG+/5uEDayRc1oCxD3cYByDnN41BGTY/DVS1HRD; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 9759 invoked from network); 11 Aug 2013 20:02:01 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.64?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 11 Aug 2013 20:02:01 +0200 Message-ID: <5207D199.9000207@gondrom.org> Date: Sun, 11 Aug 2013 19:02:01 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: trevp@trevp.net References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520776C0.9080202@gondrom.org> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------050502030708070106000801" Cc: websec@ietf.org Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 11 Aug 2013 18:09:45 -0000 This is a multi-part message in MIME format. --------------050502030708070106000801 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/08/13 16:54, Trevor Perrin wrote: > On Sun, Aug 11, 2013 at 4:34 AM, Tobias Gondrom > wrote: >> Hi all, >> >> >> >> A small question about pinning to names and uniqueness of "pinned names": >> Under which conditions could the following attack scenario be a problem >> and what would we do about it? >> >> Domain A has bought a cert from CA-11 with the name "super safe" and >> pins to the name instead of the cert. >> CA-11 could be an intermediate for CA-1 with the name "uber super safe". >> Which names could we pin to? >> - the intermediate CA-1 and/or CA-11? >> >> Now wondering whether the following is a problem: >> attacker gains control over CA-2 (either through an attack or through >> government influence) and issues a certificate for an intermediate >> CA-11' with the name "super safe". > > Yes, that's a problem. Gerv also brought up the "DigiCert" name collision. > > So using names as a "layer of indirection" to point to a set of > CA-declared keys seems better than trying to pin to names as they > appear in certs. > > > Trevor Thank you for the clarification. In that case I would prefer not to pin to names. As the above scenario is exactly the one we wanted to avoid in the first place. We need to allow a domain to link to one specific cert or a specific set of certs (like from one specified CA), and by this avoid that they are exposed to risks by a breach of any other CA. If we really need a to pin to a group of certs, maybe one other idea might be to allow to pin to a top-node of a CA directly (but not intermediaries as we would have the same attack scenario with them, too.) Best regards, Tobias --------------050502030708070106000801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/08/13 16:54, Trevor Perrin wrote:
On Sun, Aug 11, 2013 at 4:34 AM, Tobias Gondrom
<tobias.gondrom@gondrom.org> wrote:

Hi all,

<no hats>

A small question about pinning to names and uniqueness of "pinned names":
Under which conditions could the following attack scenario be a problem
and what would we do about it?

Domain A has bought a cert from CA-11 with the name "super safe" and
pins to the name instead of the cert.
CA-11 could be an intermediate for CA-1 with the name "uber super safe".
Which names could we pin to?
- the intermediate CA-1 and/or CA-11?

Now wondering whether the following is a problem:
attacker gains control over CA-2 (either through an attack or through
government influence) and issues a certificate for an intermediate
CA-11' with the name "super safe".


Yes, that's a problem.  Gerv also brought up the "DigiCert" name collision.

So using names as a "layer of indirection" to point to a set of
CA-declared keys seems better than trying to pin to names as they
appear in certs.


Trevor

Thank you for the clarification.
In that case I would prefer not to pin to names. As the above scenario is exactly the one we wanted to avoid in the first place.
We need to allow a domain to link to one specific cert or a specific set of certs (like from one specified CA), and by this avoid that they are exposed to risks by a breach of any other CA.

If we really need a to pin to a group of certs, maybe one other idea might be to allow to pin to a top-node of a CA directly (but not intermediaries as we would have the same attack scenario with them, too.)

Best regards, Tobias

 --------------050502030708070106000801-- From trevp@trevp.net Sun Aug 11 11:19:21 2013 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 5189A21F9D92 for ; Sun, 11 Aug 2013 11:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwANFdvxNFsW for ; Sun, 11 Aug 2013 11:19:15 -0700 (PDT) Received: from mail-wg0-f67.google.com (mail-wg0-f67.google.com [74.125.82.67]) by ietfa.amsl.com (Postfix) with ESMTP id A99C521F9DBD for ; Sun, 11 Aug 2013 11:12:19 -0700 (PDT) Received: by mail-wg0-f67.google.com with SMTP id z12so1778894wgg.2 for ; Sun, 11 Aug 2013 11:12:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FEEiPDBujn5d/NbIy5Dwb8kiXUNNtTw5Koyn/428bko=; b=eprJ7DIOAlPiscu/ZiZrTvteWoFvvF9aRf/zvUU4Pn2VzRJcNSLO2MfAV4AhZDndkm 864mLFVa0XugtHWSWu3OWVoKYrUuxGdU55W+5L6afpUgQ6yclKd2x1qBbLV19Fsx8IhA 6NgLkJ5nFA3sIylpfA5puGHJRDcgCHVmp589yB9tURQWpmbP6Pqx5Byjex2Yb02U9Wg4 D4p6ZvZHhqvAlDSZf9bYXsWaZ9mXt3zdlrGkwr7VIxKkQkmw2ras54t4qvXHyxp6rBpi yzmty1zLFY/hh/A9O8Vz9SLnrLVQQ7CaCGZEZfjATJ2wCCrWvjyzaBtloToL7ioiL59P XPmg== X-Gm-Message-State: ALoCoQnXnx3UajGPXEhj1qgw/Znxlvm//MlceLd14YlV2tmjKUY1NVr/noTbf5ZFng2rGhWlGcDk MIME-Version: 1.0 X-Received: by 10.194.202.230 with SMTP id kl6mr10898577wjc.9.1376244738786; Sun, 11 Aug 2013 11:12:18 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Sun, 11 Aug 2013 11:12:18 -0700 (PDT) X-Originating-IP: [50.37.31.184] In-Reply-To: <5207D199.9000207@gondrom.org> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520776C0.9080202@gondrom.org> <5207D199.9000207@gondrom.org> Date: Sun, 11 Aug 2013 11:12:18 -0700 Message-ID: From: Trevor Perrin To: Tobias Gondrom Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 11 Aug 2013 18:19:21 -0000 On Sun, Aug 11, 2013 at 11:02 AM, Tobias Gondrom wrote: > > Thank you for the clarification. > In that case I would prefer not to pin to names. I'd prefer not to pin to X.509 Subject Names too. What Phil, myself, and others are suggesting is pinning to a domain name held by the CA as a way of indirectly pinning the set of SPKIs under which that CA issues certificates. Because this set may contain several SPKIs, and because it will change over time, this seems a more user-friendly approach than pinning SPKIs directly. Trevor From ynir@checkpoint.com Sun Aug 11 11:59:04 2013 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 31F7621F9A51 for ; Sun, 11 Aug 2013 11:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRJ6pT4CJYR7 for ; Sun, 11 Aug 2013 11:58:59 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4EF11E8124 for ; Sun, 11 Aug 2013 11:53:20 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7BIrD8M008529; Sun, 11 Aug 2013 21:53:14 +0300 X-CheckPoint: {5207DD99-23-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Sun, 11 Aug 2013 21:53:13 +0300 From: Yoav Nir To: Trevor Perrin Thread-Topic: [websec] #58: Should we pin only SPKI, or also names Thread-Index: AQHOjHagv3/BmvZ4wU6WrbkIw+Bd/ZmAXZOAgAADk4CAAHu6gIAIRDGAgAJ+5gCAA6qMgIAAd7oAgABIiACAACPEgIAAAuAAgAALc4A= Date: Sun, 11 Aug 2013 18:53:12 +0000 Message-ID: <9B14206B-5B73-4F91-9F54-3A2F651F768F@checkpoint.com> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520776C0.9080202@gondrom.org> <5207D199.9000207@gondrom.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.158] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11818d8010b0da324de48636acb3c5b03394bed426 Content-Type: text/plain; charset="us-ascii" Content-ID: <5787D72DA92DC94CA8F716716AFE173B@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 11 Aug 2013 18:59:04 -0000 On Aug 11, 2013, at 9:12 PM, Trevor Perrin wrote: > On Sun, Aug 11, 2013 at 11:02 AM, Tobias Gondrom > wrote: >>=20 >> Thank you for the clarification. >> In that case I would prefer not to pin to names. >=20 > I'd prefer not to pin to X.509 Subject Names too. >=20 > What Phil, myself, and others are suggesting is pinning to a domain > name held by the CA as a way of indirectly pinning the set of SPKIs > under which that CA issues certificates. >=20 > Because this set may contain several SPKIs, and because it will change > over time, this seems a more user-friendly approach than pinning SPKIs > directly. Hi Trevor.=20 That would save us from a registry, but pinning is different from CAA. A CA= A record is made to be read by either humans or humans aided by machines.=20 If I advertise a CAA record for my domain with the FQDN "instantssl.com", t= hen InstartSSL will issue me a certificate, probably in an automated proces= s. If instead, I say "comodo.com", this might be flagged, but probably auth= orized in the end. If it says "Kommodo", eventually a human is going to loo= k at it and decide what the intent was, perhaps with a question by email. In key pinning, this decision is entirely for a computer to make. So the br= owser will need to untangle the mess of domain names that certificate vendo= rs own due to mergers, acquisitions, and simple branding. Worse - without a= centrally-maintained list different browsers might untangle it differently= , and administrators will have to guess what works. Yoav From trevp@trevp.net Sun Aug 11 12:43:45 2013 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 985B021F9BDB for ; Sun, 11 Aug 2013 12:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XETy-mwbr83 for ; Sun, 11 Aug 2013 12:43:41 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8341111E80FF for ; Sun, 11 Aug 2013 12:36:28 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id q55so4846392wes.2 for ; Sun, 11 Aug 2013 12:36:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=achc6Ko4VteFMqN3yH8alhJRalFAsLMNm5fr0QSJLx4=; b=LdqNQ0Ng2eSOgkMfnoHpN6iBJdCs7TbDNphXAYyvDyA2l8uF2Na2w0VSJcBzpJ6TsP cjT0quhuuglAMDRAyyTARbSf8/KryymCzF9YhO0NrpoK6ddcLJx6GvYmab1IxoT5Vh/t XclX+V4Url6trRBmbFWKJoEOi/X5/3JuCqhJoaKEXdFDm0s3pU9gxKr9dzRBsyS0+MeA BBdF8sGg99cZ9u/bByFg6C2h9UHZN7j5bP1nexbk2LEod1ABWfo4vD2CF2mDN/ALVvCF jHwBKWmfXLmrczh7UfIpVCvB+aMr8t9IEJfRyDha9yxjTU4dY2v6gyOVNSuk6VkvSdRP 6P8w== X-Gm-Message-State: ALoCoQmVnmySaHqSsp6TkiVyzbLkXFGeDTsQMGPhTsewxzhHXIGI4lwgbSCTP5XCfVkbHS160H+J MIME-Version: 1.0 X-Received: by 10.180.205.236 with SMTP id lj12mr4760344wic.22.1376249788217; Sun, 11 Aug 2013 12:36:28 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Sun, 11 Aug 2013 12:36:28 -0700 (PDT) X-Originating-IP: [50.37.31.184] In-Reply-To: <9B14206B-5B73-4F91-9F54-3A2F651F768F@checkpoint.com> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520776C0.9080202@gondrom.org> <5207D199.9000207@gondrom.org> <9B14206B-5B73-4F91-9F54-3A2F651F768F@checkpoint.com> Date: Sun, 11 Aug 2013 12:36:28 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 11 Aug 2013 19:43:45 -0000 On Sun, Aug 11, 2013 at 11:53 AM, Yoav Nir wrote: > > If I advertise a CAA record for my domain with the FQDN "instantssl.com",= then InstartSSL will issue me a certificate, probably in an automated proc= ess. If instead, I say "comodo.com", this might be flagged, but probably au= thorized in the end. If it says "Kommodo", eventually a human is going to l= ook at it and decide what the intent was, perhaps with a question by email. > > In key pinning, this decision is entirely for a computer to make. So the = browser will need to untangle the mess of domain names that certificate ven= dors own due to mergers, acquisitions, and simple branding. Worse - without= a centrally-maintained list different browsers might untangle it different= ly, and administrators will have to guess what works. CAs would tell browser vendors what names to use, and which keys those correspond to. I don't think browser vendors should try to infer this on their own, as you're implying. Having some sort of clearinghouse that aggregates info from CAs and makes it available to browser vendors might be useful. But this is security-relevant info, so browser vendors might also prefer to query this from CAs themselves. So there are design decisions here that I'm arguing can be kicked down the road. In the short term (say the next year), we would be lucky if 3 browsers and a half dozen CAs wanted to experiment with this. This is small enough that it can be coordinated manually. If named pinning proves useful and lots of other CAs and browsers want to sign up, a more scaleable process can be designed then. Trevor From internet-drafts@ietf.org Sun Aug 11 13:57:20 2013 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 3A0F521F8425; Sun, 11 Aug 2013 13:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgsPft1qtcGd; Sun, 11 Aug 2013 13:57:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C63611E811E; Sun, 11 Aug 2013 13:50:55 -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.70.p1 Message-ID: <20130811205055.28088.67539.idtracker@ietfa.amsl.com> Date: Sun, 11 Aug 2013 13:50:55 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-x-frame-options-08.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: Sun, 11 Aug 2013 20:57:20 -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 Header Field X-Frame-Options Author(s) : David Ross Tobias Gondrom Filename : draft-ietf-websec-x-frame-options-08.txt Pages : 11 Date : 2013-08-11 Abstract: To improve the protection of web applications against Clickjacking, this definition describes the X-Frame-Options HTTP response header field that declares a policy communicated from the server to the client browser on whether the browser may display the transmitted content in frames that are part of other web pages. This informational document serves to document the existing use and specification of this X-Frame-Options HTTP response header field. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-x-frame-options-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Aug 11 13:57:20 2013 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 AA34B21F9E98 for ; Sun, 11 Aug 2013 13:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaPnfanQwg4E; Sun, 11 Aug 2013 13:57:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3843811E8122; Sun, 11 Aug 2013 13:50:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: websec-chairs@tools.ietf.org, draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130811205055.28088.97751.idtracker@ietfa.amsl.com> Date: Sun, 11 Aug 2013 13:50:55 -0700 Subject: [websec] New Version Notification - draft-ietf-websec-x-frame-options-08.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: Sun, 11 Aug 2013 20:57:20 -0000 A new version (-08) has been submitted for draft-ietf-websec-x-frame-option= s: http://www.ietf.org/internet-drafts/draft-ietf-websec-x-frame-options-08.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-x-frame-options-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From trac+websec@trac.tools.ietf.org Sun Aug 11 14:01:16 2013 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 A38C121F9BF0 for ; Sun, 11 Aug 2013 14:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPmyAoi0ZJY2 for ; Sun, 11 Aug 2013 14:01:16 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B6F3F21E8089 for ; Sun, 11 Aug 2013 13:56:07 -0700 (PDT) Received: from localhost ([127.0.0.1]:54012 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1V8cg7-0007W1-UI; Sun, 11 Aug 2013 22:55:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "websec issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-websec-key-pinning@tools.ietf.org, ynir@checkpoint.com X-Trac-Project: websec Date: Sun, 11 Aug 2013 20:55:55 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/59#comment:1 Message-ID: <075.0f4969841dac1b1f46b0e46c52d2aa85@trac.tools.ietf.org> References: <060.baff63c76c3965bf04b0fab1f8cc5ab7@trac.tools.ietf.org> X-Trac-Ticket-ID: 59 In-Reply-To: <060.baff63c76c3965bf04b0fab1f8cc5ab7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-websec-key-pinning@tools.ietf.org, ynir@checkpoint.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cevans@google.com, palmer@google.com, sleevi@google.com Resent-Message-Id: <20130811205607.B6F3F21E8089@ietfa.amsl.com> Resent-Date: Sun, 11 Aug 2013 13:56:07 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #59: Is the interaction between pre-loaded pins and dynamic pins clear? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 21:01:16 -0000 #59: Is the interaction between pre-loaded pins and dynamic pins clear? Changes (by ynir@checkpoint.com): * status: new => closed * resolution: => wontfix Comment: The current text reflects working group consensus. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-key- ynir@checkpoint.com | pinning@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: key-pinning | Version: Severity: In WG Last | Resolution: wontfix Call | Keywords: HPKP | -------------------------+------------------------------------------------- Ticket URL: websec From ynir@checkpoint.com Sun Aug 11 14:29:03 2013 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 7796E11E8123 for ; Sun, 11 Aug 2013 14:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.906 X-Spam-Level: X-Spam-Status: No, score=-9.906 tagged_above=-999 required=5 tests=[AWL=-0.547, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0x2OlcNwJwB for ; Sun, 11 Aug 2013 14:28:58 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 643EE21F9C34 for ; Sun, 11 Aug 2013 14:22:02 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7BLLwCB023722; Mon, 12 Aug 2013 00:21:58 +0300 X-CheckPoint: {52080076-19-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Mon, 12 Aug 2013 00:21:57 +0300 From: Yoav Nir To: Trevor Perrin Thread-Topic: [websec] #58: Should we pin only SPKI, or also names Thread-Index: AQHOjHagv3/BmvZ4wU6WrbkIw+Bd/ZmAXZOAgAADk4CAAHu6gIAIRDGAgAJ+5gCAA6qMgIAAd7oAgABIiACAACPEgIAAAuAAgAALc4CAAAwRAIAAHX2A Date: Sun, 11 Aug 2013 21:21:57 +0000 Message-ID: References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520776C0.9080202@gondrom.org> <5207D199.9000207@gondrom.org> <9B14206B-5B73-4F91-9F54-3A2F651F768F@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.158] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 111869e40d3a3f30a482a3282fe24a3049d2b2b18e Content-Type: text/plain; charset="iso-8859-1" Content-ID: <88AC540F92E3514F84685E4646198C05@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 11 Aug 2013 21:29:03 -0000 Hi All comments below are made as an individual. On Aug 11, 2013, at 10:36 PM, Trevor Perrin wrote: > On Sun, Aug 11, 2013 at 11:53 AM, Yoav Nir wrote: >>=20 >> If I advertise a CAA record for my domain with the FQDN "instantssl.com"= , then InstartSSL will issue me a certificate, probably in an automated pro= cess. If instead, I say "comodo.com", this might be flagged, but probably a= uthorized in the end. If it says "Kommodo", eventually a human is going to = look at it and decide what the intent was, perhaps with a question by email= . >>=20 >> In key pinning, this decision is entirely for a computer to make. So the= browser will need to untangle the mess of domain names that certificate ve= ndors own due to mergers, acquisitions, and simple branding. Worse - withou= t a centrally-maintained list different browsers might untangle it differen= tly, and administrators will have to guess what works. >=20 > CAs would tell browser vendors what names to use, and which keys those > correspond to. I don't think browser vendors should try to infer this > on their own, as you're implying. >=20 > Having some sort of clearinghouse that aggregates info from CAs and > makes it available to browser vendors might be useful. But this is > security-relevant info, so browser vendors might also prefer to query > this from CAs themselves. There is a third party here. The web site administrators need to set one of= those strings in the key pinning data, so they should be able to obtain th= e correct strings. There may be only 3 browsers and half a dozen CAs that w= ould want to experiment with this, but there may be a lot more web sites. T= he CAs could add it to their websites: "use 'ca.example.com' for RFC 7xxx k= ey pinning". But I think we will get some pushback in either IETF last call= or in IESG review if we try to kick it down the road. > So there are design decisions here that I'm arguing can be kicked down > the road. In the short term (say the next year), we would be lucky if > 3 browsers and a half dozen CAs wanted to experiment with this. This > is small enough that it can be coordinated manually. Experimentation is tricky. A pin is matched if one of the keys match, so if= use the example from the draft: Public-Key-Pins: max-age=3D2592000; pin-sha1=3D"4n972HfV354KP560yw4uqe/baXc=3D"; pin-sha256=3D"LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=3D" The next time the UA connect it will check that the completed server cert c= hain has either of those pins somewhere in the chain. Now let's replace th= e second pin with a named one. Assume that I have a certificate matching th= e first pin, but my next certificate is going to be from ca.example.com: Public-Key-Pins: max-age=3D2592000; pin-sha1=3D"4n972HfV354KP560yw4uqe/baXc=3D"; pin-named=3D"ca.example.com" When the UA connects again, the new certificate is there. The first pin no = longer matches, so we need the browser to be able to verify that the new ce= rtificate matches ca.example.com. Once that is in some web sites, you can't= stop the experiment. You'd have to go to each and every website that uses = this pin and remove it.=20 > If named pinning proves useful and lots of other CAs and browsers want > to sign up, a more scaleable process can be designed then. If I was assigned to do the SecDir review on this, I would push back on thi= s. Yoav From trevp@trevp.net Sun Aug 11 14:45:14 2013 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 868AF21F84CD for ; Sun, 11 Aug 2013 14:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1-epc3fW6rw for ; Sun, 11 Aug 2013 14:45:08 -0700 (PDT) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3943011E80D3 for ; Sun, 11 Aug 2013 14:39:42 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u57so4912269wes.37 for ; Sun, 11 Aug 2013 14:39:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zkDXCPfvK7HWMP9IL98m0nkaH0iVLJsRS1H1GfS0QW4=; b=NI1wGpsQt6ovoOgpbT5N/IS2W/Rww0TIT7kJgujUpmCYUCLArmGqh399PkyH/flSZI SMUCgTlQNC04SGqJmoaMCOvbbU4KVKuAHZbp8pgAFnA+oX9o1OHDh/vvJtVlU8ySrFLP mRHtykc3s0zU2PBb/OOUYVqMqHqaYids3qflpUZBvdgY7mGHjCwNQ4obz6MwZsiqeq1i vB4YqUmmrt05h0NPqGF6wjG9TiJV0pLXT4K7Qf8xacUvL5bCtihP4nrPSlDuOv56x4e/ EmVmwSou/PiTq+sh2p7qA5uBsRC4CAqhi9iKyIn2FyNDvqbcYyPPF2K3469eImSpLJk5 dtxA== X-Gm-Message-State: ALoCoQmhbDb58OrOS75RvHdTr8b3UydeED/6Ky288yfyYtz0UtTMPQxpaAw80VRognFKBFTdjmZS MIME-Version: 1.0 X-Received: by 10.180.20.4 with SMTP id j4mr4890952wie.48.1376257181000; Sun, 11 Aug 2013 14:39:41 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Sun, 11 Aug 2013 14:39:40 -0700 (PDT) X-Originating-IP: [50.37.31.184] In-Reply-To: References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520776C0.9080202@gondrom.org> <5207D199.9000207@gondrom.org> <9B14206B-5B73-4F91-9F54-3A2F651F768F@checkpoint.com> Date: Sun, 11 Aug 2013 14:39:40 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 11 Aug 2013 21:45:14 -0000 On Sun, Aug 11, 2013 at 2:21 PM, Yoav Nir wrote: > There is a third party here. The web site administrators need to set one = of those strings in the key pinning data, so they should be able to obtain = the correct strings. There may be only 3 browsers and half a dozen CAs that= would want to experiment with this, but there may be a lot more web sites.= The CAs could add it to their websites: "use 'ca.example.com' for RFC 7xxx= key pinning". Sure, the CAs would tell their website customers what to use. > Experimentation is tricky. [...] > When the UA connects again, the new certificate is there. The first pin n= o longer matches, so we need the browser to be able to verify that the new = certificate matches ca.example.com. Once that is in some web sites, you can= 't stop the experiment. You'd have to go to each and every website that use= s this pin and remove it. It's easy to stop. A browser that doesn't want to support named pins could ignore any HPKP headers containing them. If all browsers do this, then HPKP is back to pure-SPKI pinning. >> If named pinning proves useful and lots of other CAs and browsers want >> to sign up, a more scaleable process can be designed then. > > If I was assigned to do the SecDir review on this, I would push back on t= his. Why? Trevor From ynir@checkpoint.com Sun Aug 11 20:58:43 2013 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 8BB9421F9DB2 for ; Sun, 11 Aug 2013 20:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.517 X-Spam-Level: X-Spam-Status: No, score=-10.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpeIhGU8P0oG for ; Sun, 11 Aug 2013 20:58:37 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7813021F9C72 for ; Sun, 11 Aug 2013 20:52:18 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7C3qFuR020163; Mon, 12 Aug 2013 06:52:15 +0300 X-CheckPoint: {52085BEF-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Mon, 12 Aug 2013 06:52:14 +0300 From: Yoav Nir To: Trevor Perrin Thread-Topic: [websec] #58: Should we pin only SPKI, or also names Thread-Index: AQHOjHagv3/BmvZ4wU6WrbkIw+Bd/ZmAXZOAgAADk4CAAHu6gIAIRDGAgAJ+5gCAA6qMgIAAd7oAgABIiACAACPEgIAAAuAAgAALc4CAAAwRAIAAHX2AgAAE7wCAAGgggA== Date: Mon, 12 Aug 2013 03:52:14 +0000 Message-ID: <1A99AD15-D0D3-4EFB-9365-58BC0EDAD54E@checkpoint.com> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520776C0.9080202@gondrom.org> <5207D199.9000207@gondrom.org> <9B14206B-5B73-4F91-9F54-3A2F651F768F@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.253] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11a288213a60724dca2faef22ecc8abd1262ecca37 Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 12 Aug 2013 03:58:43 -0000 On Aug 12, 2013, at 12:39 AM, Trevor Perrin wrote: >=20 >>> If named pinning proves useful and lots of other CAs and browsers want >>> to sign up, a more scaleable process can be designed then. >>=20 >> If I was assigned to do the SecDir review on this, I would push back on = this. >=20 > Why? Because that leave a part of the protocol that can't be implemented unless = something happens that we don't specify. Because only the big name browsers, who can get information directly from C= As will be able to implement this. Because the list of acceptable strings would need to be updated often, and = absent a registry, this means software update, and we shouldn't rely on tho= se. Because the chances of a misconfiguration resulting in a blocked site seem = to me to be too high. Yoav= From trevp@trevp.net Sun Aug 11 22:59:05 2013 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 7D5A721F9E73 for ; Sun, 11 Aug 2013 22:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhOfOM4Y+nXw for ; Sun, 11 Aug 2013 22:58:59 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by ietfa.amsl.com (Postfix) with ESMTP id D51B521F99EC for ; Sun, 11 Aug 2013 22:53:09 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id l18so1252142wgh.2 for ; Sun, 11 Aug 2013 22:53:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Vc5/TwqAp1UxMN5YGPBoVXd7RneiYjsWzULfZfY8BSo=; b=TASmJGmXCn1zxXkNambHpEbSauxsvESFsROnzLfiUnpST7ec8fOXLWV8mZpPumsLn1 sbljtuLCU8aOK4QBovIjYTMZtl7TUaLD2Lr+EeHiBV43RWdOQ82qpNmXannTVbzM9XLF OekxsBnGjml1rKarMP3H31BZKbh4/CjiedlrRYbXdAHWWf5gcheebLBrzSN6G9vsvcF0 ZnIfsw88Kv0oDnBR04bgySRGo/1QglYLQL7JDmiYsro3lBMIS1n7SXJcGZF4Tq35+/25 srhuR1gkb5uquUl0RebZnsj2e9KO3ILm/Zhr4U32Hxr/YUfcMbLRstPKwn/QpGqWTo35 trrA== X-Gm-Message-State: ALoCoQljRUefdIzcUiI6HTEWPip4lkPXbD9gt4DbyzythKi0W/GImubc/Uo/P24codwReN9iE2Yr MIME-Version: 1.0 X-Received: by 10.180.189.104 with SMTP id gh8mr5569872wic.48.1376286788699; Sun, 11 Aug 2013 22:53:08 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Sun, 11 Aug 2013 22:53:08 -0700 (PDT) X-Originating-IP: [50.37.31.184] In-Reply-To: <075.0f4969841dac1b1f46b0e46c52d2aa85@trac.tools.ietf.org> References: <060.baff63c76c3965bf04b0fab1f8cc5ab7@trac.tools.ietf.org> <075.0f4969841dac1b1f46b0e46c52d2aa85@trac.tools.ietf.org> Date: Sun, 11 Aug 2013 22:53:08 -0700 Message-ID: From: Trevor Perrin To: websec issue tracker Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-websec-key-pinning@tools.ietf.org, IETF WebSec WG Subject: Re: [websec] #59: Is the interaction between pre-loaded pins and dynamic pins clear? 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, 12 Aug 2013 05:59:05 -0000 On Sun, Aug 11, 2013 at 1:55 PM, websec issue tracker wrote: > #59: Is the interaction between pre-loaded pins and dynamic pins clear? Still needs discussion, in particular: * Preloaded pin stores will be periodically updated, which means browsers will need to handle "backdated" pins, i.e. pins that are received *after* other HPKP observations but have an "Effective Pin Date" which is earlier. To handle these in accordance with 2.7 requires browsers to remember "un-pinning" observations (expired pins, max-age=0, or nonexistent HPKP headers). This is sufficiently complex that the spec needs some treatment of it. * 2.7 mandates that the most recent observation from any source MUST take priority. Browsers would not be allowed to implement other priority rules, such as prioritizing one source over another, prioritizing fail-open or fail-closed behavior, or anything else. I believe this is overly restrictive. Some browsers might prefer different policies, e.g. simpler policies that don't require tracking "un-pinning" data. When I brought these points up earlier, the two responses were supportive of loosening the rules in 2.7. I hadn't responded to Yoav's latest query because I'm overloaded with HPKP discussion, and assumed everyone else was too. So I suggest we keep this open, and revisit once other discussions quiet down. Trevor From trac+websec@trac.tools.ietf.org Sun Aug 11 23:32:38 2013 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 97D8E21F8F4F for ; Sun, 11 Aug 2013 23:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3lj1ESxZlGg for ; Sun, 11 Aug 2013 23:32:38 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id D736721F9473 for ; Sun, 11 Aug 2013 23:25:17 -0700 (PDT) Received: from localhost ([127.0.0.1]:53175 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1V8lYx-0001tm-0e; Mon, 12 Aug 2013 08:25:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "websec issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-websec-key-pinning@tools.ietf.org, ynir@checkpoint.com X-Trac-Project: websec Date: Mon, 12 Aug 2013 06:25:06 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/websec/trac/ticket/59#comment:2 Message-ID: <075.11fff05abc96a8378a484dd89905c6f7@trac.tools.ietf.org> References: <060.baff63c76c3965bf04b0fab1f8cc5ab7@trac.tools.ietf.org> X-Trac-Ticket-ID: 59 In-Reply-To: <060.baff63c76c3965bf04b0fab1f8cc5ab7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-websec-key-pinning@tools.ietf.org, ynir@checkpoint.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cevans@google.com, palmer@google.com, sleevi@google.com Resent-Message-Id: <20130812062517.D736721F9473@ietfa.amsl.com> Resent-Date: Sun, 11 Aug 2013 23:25:17 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #59: Is the interaction between pre-loaded pins and dynamic pins clear? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 06:32:38 -0000 #59: Is the interaction between pre-loaded pins and dynamic pins clear? Changes (by ynir@checkpoint.com): * status: closed => reopened * resolution: wontfix => Comment: Got a clarification from Trevor: http://www.ietf.org/mail-archive/web/websec/current/msg01833.html -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-key- ynir@checkpoint.com | pinning@tools.ietf.org Type: defect | Status: reopened Priority: major | Milestone: Component: key-pinning | Version: Severity: In WG Last | Resolution: Call | Keywords: HPKP | -------------------------+------------------------------------------------- Ticket URL: websec From iesg-secretary@ietf.org Mon Aug 12 00:24:54 2013 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 543E521F9A65; Mon, 12 Aug 2013 00:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRIPxEuz8xpA; Mon, 12 Aug 2013 00:24:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCC911E8145; Mon, 12 Aug 2013 00:12:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: DraftTracker Mail System To: iesg@ietf.org, websec-chairs@tools.ietf.org, draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130812071245.9789.70890.idtracker@ietfa.amsl.com> Date: Mon, 12 Aug 2013 00:12:45 -0700 Cc: iesg-secretary@ietf.org Subject: [websec] Last Call Expired: 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, 12 Aug 2013 07:24:54 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-o= ptions/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From trevp@trevp.net Mon Aug 12 00:26:09 2013 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 7895721F9A51 for ; Mon, 12 Aug 2013 00:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1+hldx-784X for ; Mon, 12 Aug 2013 00:26:03 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5180A21F9B0E for ; Mon, 12 Aug 2013 00:13:10 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id u55so5210209wes.27 for ; Mon, 12 Aug 2013 00:13:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/4PgHm1cJuFZcIEVSTJdwpxGe9wzZ7CmX7///GV9ZGA=; b=Zmn4BcXnVBN8wdg8Eme37Wuui/iSNIVekUTDPCwvUeCvT5bUY55nrjmsG+Yq5RLY2i /1fa8YFs93Y7JooGaDlsx3tqXQEmo5sQpi1OEudwrEpL6l/yOpvfoGXciitPcS8tm9v8 IdLxEwEj5iNm1oeKbGCtuCx33NE6c0qWQUf1HESU3L707fMfxnvsftk6U8LeIAd1CIUf fih2OI4Bk8TgcOFkW7ZVm2w4tMwLD33btIg3Fq9OM+plyMNGOct7AnhK6d/KIRu5ZD+7 5volmofKnmqu4zYkzv5EBRWPO7Pun8+3IMdB/Nzo1qMOMuyZahsezxI3ALVOnZRXHa4N yLEQ== X-Gm-Message-State: ALoCoQkwZjtqreDlKNchbnGsGbcQQPKIHSZA9faIZylMxp4Yr2Dlb27G0RQFS4cbZiHmhJZJGGdD MIME-Version: 1.0 X-Received: by 10.180.10.202 with SMTP id k10mr5643095wib.17.1376291590248; Mon, 12 Aug 2013 00:13:10 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Mon, 12 Aug 2013 00:13:10 -0700 (PDT) X-Originating-IP: [50.37.31.184] In-Reply-To: <1A99AD15-D0D3-4EFB-9365-58BC0EDAD54E@checkpoint.com> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <520776C0.9080202@gondrom.org> <5207D199.9000207@gondrom.org> <9B14206B-5B73-4F91-9F54-3A2F651F768F@checkpoint.com> <1A99AD15-D0D3-4EFB-9365-58BC0EDAD54E@checkpoint.com> Date: Mon, 12 Aug 2013 00:13:10 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 12 Aug 2013 07:26:09 -0000 On Sun, Aug 11, 2013 at 8:52 PM, Yoav Nir wrote: > > On Aug 12, 2013, at 12:39 AM, Trevor Perrin wrote: >> >>>> If named pinning proves useful and lots of other CAs and browsers want >>>> to sign up, a more scaleable process can be designed then. >>> >>> If I was assigned to do the SecDir review on this, I would push back on this. >> >> Why? > > Because that leave a part of the protocol that can't be implemented unless something happens that we don't specify. Browser TLS already depends on coordination between browsers, CAs, and websites that is outside the scope of RFCs like 5246. It's not surprising that improving browser TLS might require additional coordination between these parties. This coordination could happen in various ways, and would probably evolve over time. It's also orthogonal to the on-the-wire protocol. So it seems reasonable to leave it outside the current document's scope. > Because only the big name browsers, who can get information directly from CAs will be able to implement this. Why would the CAs only provide this information to "big name browsers"? Why wouldn't they publish it? In any case, we're fortunate that two of the "big name browsers" represented in this thread are built on open source, so their actions can be observed and learnt from, and their code reused. If they work with CAs to coordinate named pinning, it would be beneficial to the public at large. > Because the list of acceptable strings would need to be updated often, and absent a registry, this means software update, and we shouldn't rely on those. Browsers already receive updates for many types of information (root store updates, security patches, blacklists for malware and phishing sites, revocation data, etc.) > Because the chances of a misconfiguration resulting in a blocked site seem to me to be too high. Seems quite the reverse to me. The risk of HPKP misconfiguration seems much greater if each individual website has to figure out and track key pins for their CAs. Trevor From gerv@mozilla.org Mon Aug 12 03:05:38 2013 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 EEDD111E8156 for ; Mon, 12 Aug 2013 03:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_BACKHAIR_23=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oc-eCk6MAMnG for ; Mon, 12 Aug 2013 03:05:24 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id D820711E80F6 for ; Mon, 12 Aug 2013 01:17:58 -0700 (PDT) Received: from [192.168.0.101] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 8FADAF22FA; Mon, 12 Aug 2013 01:17:57 -0700 (PDT) Message-ID: <52089A35.9040103@mozilla.org> Date: Mon, 12 Aug 2013 09:17:57 +0100 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Trevor Perrin References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 12 Aug 2013 10:05:43 -0000 On 11/08/13 05:25, Trevor Perrin wrote: > Could we just say: > - The holder of a domain name is responsible for specifying the SPKIs > that it maps to. > - How the domain holder communicates this to the UA is out of scope. In other words "Don't set up a registry; just punt the problem and hope something works itself out organically"? > So it seems best to separate this from HPKP, and advance HPKP now in a > way that lets us experiment with named pinning. The hard work of > building a scaleable system for CA<->key mapping can be postponed > until it's necessary and we have a better understanding of > requirements. I think there will be problems with people not being protected who expect to be, if you allow this sort of pinning into the spec but leave entirely undefined the mechanisms for communicating what it actually should mean when someone pins to a name. Gerv From tobias.gondrom@gondrom.org Mon Aug 12 04:34:35 2013 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 1505A21F995E for ; Mon, 12 Aug 2013 04:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.611 X-Spam-Level: X-Spam-Status: No, score=-95.611 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pq11xzFnmReV for ; Mon, 12 Aug 2013 04:34:30 -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 6702521F9E33 for ; Mon, 12 Aug 2013 03:47:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=bwy8toCqIpr+17F8TlOFmowFlT7tAska1cp4T/zzLD3688p6B+BH+5nW+fG+DsrJ3tuFtlHB6aFGX0EckgDaBCLix5rmIyF0bUQ045ONXbBncjd7V3L5N11bXYMkP1Gv; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 14117 invoked from network); 12 Aug 2013 12:47:57 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.64?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Aug 2013 12:47:57 +0200 Message-ID: <5208BD5D.6080502@gondrom.org> Date: Mon, 12 Aug 2013 11:47:57 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: jbonneau@gmail.com References: <060.e0f8fef9b2d28177be54bca787fadd87@trac.tools.ietf.org> <32D5F3CB-E742-4A9F-94A9-01B8224F9C49@checkpoint.com> <51FA1C35.1090005@mozilla.org> <4B4A645A-793F-4276-96BF-FBA5BA740632@checkpoint.com> <51FA26AD.2020405@gondrom.org> <0C788DC3-4C7F-47D4-B0A6-54E94FC5EAD0@checkpoint.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------040805030104010201000307" Cc: websec@ietf.org Subject: Re: [websec] #60: Well Known URIs vs Response Headers 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, 12 Aug 2013 11:34:35 -0000 This is a multi-part message in MIME format. --------------040805030104010201000307 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/08/13 23:15, Joseph Bonneau wrote: > > In our mind, one of the biggest factors has been "What are the > hurdles to > practical deployment?". While there is admittedly complexity from the > header approach, it's our view that it's not greater than the inherent > complexity of effective pinning, as enumerated in the existing > considerations. The complexity of an efficient and reasonable > implementation of well-known URIs, or of a practical deployment of > server > extensions, seems to greatly outweigh both, and the benefits are > not as > seemingly significant. > > > I am in agreement that a TLS extension seems like far too much to ask > of deploying sites. I'm also appreciating more and more from this > thread the difficulty of a well-known URI and though I think it's a > cleaner approach in the long-term I can see the argument that it's too > much to do right now. agree. +1 for going with http header and _not_ going with well-known URI at this point. Best regards, Tobias > > I'm fully on-board with headers if we can address two issues that I > think are real impediments to servers deploying HPKP and doing so > correctly: (a) header bloat (600 bytes of for a site requiring 10 > pins) (b) inadvertent HPKP hole-punching when resources are > accidentally served without headers set. Other issues (e.g. > discoverability by crawlers) seem secondary. > > I think we can address (b) by not interpreting a missing HPKP header > as a max-age=0, and I was hoping we could deal with (a) by clients > sending a hash or policy serial number to avoid repeatedly sending the > header. Does this approach add too much complexity given the level of > concern about header bloat, which doesn't seem huge? > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec --------------040805030104010201000307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/08/13 23:15, Joseph Bonneau wrote:

In our mind, one of the biggest factors has been "What are the hurdles to
practical deployment?". While there is admittedly complexity from the
header approach, it's our view that it's not greater than the inherent
complexity of effective pinning, as enumerated in the existing
considerations. The complexity of an efficient and reasonable
implementation of well-known URIs, or of a practical deployment of server
extensions, seems to greatly outweigh both, and the benefits are not as
seemingly significant.

I am in agreement that a TLS extension seems like far too much to ask of deploying sites. I'm also appreciating more and more from this thread the difficulty of a well-known URI and though I think it's a cleaner approach in the long-term I can see the argument that it's too much to do right now.

<no hats>
agree.
+1 for going with http header and _not_ going with well-known URI at this point.
Best regards, Tobias



I'm fully on-board with headers if we can address two issues that I think are real impediments to servers deploying HPKP and doing so correctly: (a) header bloat (600 bytes of for a site requiring 10 pins) (b) inadvertent HPKP hole-punching when resources are accidentally served without headers set. Other issues (e.g. discoverability by crawlers) seem secondary.

I think we can address (b) by not interpreting a missing HPKP header as a max-age=0, and I was hoping we could deal with (a) by clients sending a hash or policy serial number to avoid repeatedly sending the header. Does this approach add too much complexity given the level of concern about header bloat, which doesn't seem huge?


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

--------------040805030104010201000307-- From ietf-secretariat-reply@ietf.org Mon Aug 12 06:36:42 2013 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 CAD5121F8617 for ; Mon, 12 Aug 2013 06:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.441 X-Spam-Level: X-Spam-Status: No, score=-101.441 tagged_above=-999 required=5 tests=[AWL=-1.060, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pc3xVZ6HQene; Mon, 12 Aug 2013 06:36:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8432511E810E; Mon, 12 Aug 2013 06:28:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: websec-chairs@tools.ietf.org, draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130812132850.7701.8702.idtracker@ietfa.amsl.com> Date: Mon, 12 Aug 2013 06:28:50 -0700 From: IETF Secretariat X-Mailman-Approved-At: Mon, 12 Aug 2013 06:39:00 -0700 Subject: [websec] ID Tracker State Update Notice: 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, 12 Aug 2013 13:36:42 -0000 State changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-o= ptions/ From trevp@trevp.net Mon Aug 12 09:44:35 2013 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 12E4721F9D7A for ; Mon, 12 Aug 2013 09:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_BACKHAIR_23=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dq88oK8O4fxH for ; Mon, 12 Aug 2013 09:44:29 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4C11221F9C40 for ; Mon, 12 Aug 2013 09:12:10 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id q55so5667023wes.16 for ; Mon, 12 Aug 2013 09:11:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5jQDwyY9EtlJ/mRDPestCB0hRQCSbD2aRRKvO3g3VCM=; b=fMDJPfwqErlwkXZtecBCMZJvA4IzLVN0Wqp7rpAJlplRqZSYITtO0waRDf6ajxWxp0 yLB4SgDEbHXnTuODR9S0813chbcoP6pf6VUhREx1qBASdtv2Ty1xWpuv508uGk7734tW qFP3aqdBGy83maTL0nHw9tI4h1M/85Zta9FEQh3MJ76tGe5ELibE8gvnQxHkxualOksc s6Ao9fifJIi8a5/M1TS39jKRs2teuxryHodyrGBAwZZ9wnyFMl5OOHAkBUQ4JtqItVYm gprZl7bGS3GFeNsfMz7ejftIO2+ApNWPOH9wctaAlgfTuZARjPaEqPvJB9IqRNgbV9e1 VzCw== X-Gm-Message-State: ALoCoQlwmsSKVxfrSwYFS4Cy0PyNCBPYdqb2oXDMz1EGKmJyujULiLwAn7ssNPFKcy9hI1pRfLZL MIME-Version: 1.0 X-Received: by 10.194.202.230 with SMTP id kl6mr13293672wjc.9.1376323913844; Mon, 12 Aug 2013 09:11:53 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Mon, 12 Aug 2013 09:11:53 -0700 (PDT) X-Originating-IP: [166.137.187.74] In-Reply-To: <52089A35.9040103@mozilla.org> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <52089A35.9040103@mozilla.org> Date: Mon, 12 Aug 2013 09:11:53 -0700 Message-ID: From: Trevor Perrin To: Gervase Markham Content-Type: text/plain; charset=ISO-8859-1 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 12 Aug 2013 16:44:35 -0000 On Mon, Aug 12, 2013 at 1:17 AM, Gervase Markham wrote: > On 11/08/13 05:25, Trevor Perrin wrote: >> Could we just say: >> - The holder of a domain name is responsible for specifying the SPKIs >> that it maps to. >> - How the domain holder communicates this to the UA is out of scope. > > In other words "Don't set up a registry; just punt the problem and hope > something works itself out organically"? Yes. If people hate this, someone should make a proposal for a registry: - Who maintains it? - How are requests to add or remove CA names authenticated? - Does the registry map CA names to actual keys? - If so, how are change requests authenticated? - What are the timing rules to ensure changes are propagated to browsers as needed? - How can the registry be monitored and double-checked to avoid it becoming a single point of failure? - Should these process details be defined in the HPKP spec or somewhere else? >> So it seems best to separate this from HPKP, and advance HPKP now in a >> way that lets us experiment with named pinning. The hard work of >> building a scaleable system for CA<->key mapping can be postponed >> until it's necessary and we have a better understanding of >> requirements. > > I think there will be problems with people not being protected who > expect to be, if you allow this sort of pinning into the spec but leave > entirely undefined the mechanisms for communicating what it actually > should mean when someone pins to a name. Could you explain how these problems would arise? I'm proposing CAs would coordinate with browsers, then inform their customers (websites) which name to use. A misbehaving CA could inform its customers of a meaningless name, causing browsers to ignore the pin. But a misbehaving CA could violate its customers' security in other ways. Trevor From gerv@mozilla.org Mon Aug 12 10:17:05 2013 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 0CC7321F9E34 for ; Mon, 12 Aug 2013 10:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tayhZ1Q8MDWs for ; Mon, 12 Aug 2013 10:17:00 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4827521F90FD for ; Mon, 12 Aug 2013 10:04:25 -0700 (PDT) Received: from [192.168.0.101] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id BA82AF2092; Mon, 12 Aug 2013 10:04:23 -0700 (PDT) Message-ID: <52091598.7000306@mozilla.org> Date: Mon, 12 Aug 2013 18:04:24 +0100 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Trevor Perrin References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <52089A35.9040103@mozilla.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 12 Aug 2013 17:17:05 -0000 On 12/08/13 17:11, Trevor Perrin wrote: > If people hate this, someone should make a proposal for a registry: Or make a proposal to stick with the current spec, and not pin names :-) >> I think there will be problems with people not being protected who >> expect to be, if you allow this sort of pinning into the spec but leave >> entirely undefined the mechanisms for communicating what it actually >> should mean when someone pins to a name. > > Could you explain how these problems would arise? > > I'm proposing CAs would coordinate with browsers, then inform their > customers (websites) which name to use. A misbehaving CA could inform > its customers of a meaningless name, causing browsers to ignore the > pin. But a misbehaving CA could violate its customers' security in > other ways. They would arise via any of the obvious mechanisms this could go wrong, e.g.: * CA fails to communicate with (some subset of) browsers, perhaps the small ones, leading to divergent behaviour * Browser update is not universally accepted, leading to divergent behaviour Say Foo CA merges with Bar CA, and issues an edict that from now on the string "fooca.com" will include the already-deployed root, "Bar CA Super-Secure". Six months later, after gnashing their teeth at the delay that this process is introducing into their business, they start issuing certs from "Bar CA Super-Secure" to Foo CA customers. A site, naiveshop.com, is pinned to fooca.com, and buys one of these new certs. All naiveshop.com's customers whose browsers are older than 6 months get connection failures, and naiveshop.com can't easily detect that this is happening, or to how many people. Gerv From ynir@checkpoint.com Mon Aug 12 11:50:32 2013 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 2CE9621F9E1E for ; Mon, 12 Aug 2013 11:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.518 X-Spam-Level: X-Spam-Status: No, score=-10.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vj-elKYXBFH for ; Mon, 12 Aug 2013 11:50:26 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E0F6F21F9CFB for ; Mon, 12 Aug 2013 11:50:25 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7CIoAGY004346; Mon, 12 Aug 2013 21:50:10 +0300 X-CheckPoint: {52092E62-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Mon, 12 Aug 2013 21:50:09 +0300 From: Yoav Nir To: Trevor Perrin Thread-Topic: [websec] #58: Should we pin only SPKI, or also names Thread-Index: AQHOjHagv3/BmvZ4wU6WrbkIw+Bd/ZmAXZOAgAADk4CAAHu6gIAIRDGAgAJ+5gCAA6qMgIAB0yuAgACEa4CAACxEgA== Date: Mon, 12 Aug 2013 18:50:09 +0000 Message-ID: References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <52089A35.9040103@mozilla.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.254] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11cdc0158582cd0fe245be428b481686e983d19600 Content-Type: text/plain; charset="us-ascii" Content-ID: <0DD11F519EAB5C46948D915811DDE961@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 12 Aug 2013 18:50:32 -0000 On Aug 12, 2013, at 7:11 PM, Trevor Perrin wrote: > On Mon, Aug 12, 2013 at 1:17 AM, Gervase Markham wrote= : >> On 11/08/13 05:25, Trevor Perrin wrote: >>> Could we just say: >>> - The holder of a domain name is responsible for specifying the SPKIs >>> that it maps to. >>> - How the domain holder communicates this to the UA is out of scope. >>=20 >> In other words "Don't set up a registry; just punt the problem and hope >> something works itself out organically"? >=20 > Yes. >=20 > If people hate this, someone should make a proposal for a registry: >=20 > - Who maintains it? > - How are requests to add or remove CA names authenticated? > - Does the registry map CA names to actual keys? > - If so, how are change requests authenticated? > - What are the timing rules to ensure changes are propagated to > browsers as needed? > - How can the registry be monitored and double-checked to avoid it > becoming a single point of failure? > - Should these process details be defined in the HPKP spec or somewhere e= lse? As you've said, before this is for the CAs and browsers to come up with suc= h a solution (assuming they want it, and I'm not hearing this from either t= he Mozilla people or the Google people on this list). CAs and browers. Now,= if only there was some forum where both of these come together... Joking aside, The CA/Browser forum is not currently in the business of runn= ing registries. IANA is, but I don't know how to specify in a draft an IANA= policy that would include following mergers, acquisitions, and branding, a= nd settling trademark disputes. Not do I have any reason to believe that IA= NA would be willing to do this. So unless the CA/Browser Forum agrees to ta= ke on this responsibility, and provide stable link for both machine and hum= an readable mappings, I think this proposal should be shelved until we can = find someone who will answer your questions above. Yoav From jeremy.rowley@digicert.com Mon Aug 12 12:39:20 2013 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 6962B21F9B7F for ; Mon, 12 Aug 2013 12:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8esnSUAfh3m for ; Mon, 12 Aug 2013 12:39:11 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA0321F9F98 for ; Mon, 12 Aug 2013 12:39:07 -0700 (PDT) Received: from JROWLEYL1 (unknown [67.137.52.8]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id B3FD37FA068; Mon, 12 Aug 2013 13:39:02 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1376336343; bh=jMPgNeTw6SYQhZpPh5FuOrztqBCyJ524hvU3uQ4N0ZM=; h=Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date; b=DArvxySwB+dfbF5CATXW0dKSQbUyc9p2Ga44wtq4UnobfCIzIFQxiDi+PT+UaXtzq du2Diz1/+AUifY/JbnEWp1Zbjl8ioPEOn7D8AtQyb5DW/gw6oE/ECJ3F7H+Wtb5PUp TQlhlYeLCSsfzBmOb3hv2H2qVYozf+NXq5xKXwZ4= From: "Jeremy Rowley" To: "'Yoav Nir'" , "'Trevor Perrin'" References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <52089A35.9040103@mozilla.org> In-Reply-To: Date: Mon, 12 Aug 2013 13:39:02 -0600 Organization: DigiCert Message-ID: <053201ce9793$9a1dbd30$ce593790$@digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJoJKS5/1/Jv2JXKWhm99jqPYGDVAJNKJejAdJQI9sCGoZA7wM5pAdUAiWKukcBIDPIBwNTr9QiAme7tNcCJlWFCwIOi6NMAkVqOGSXl2RHoA== Content-Language: en-us Cc: 'websec' Subject: Re: [websec] #58: Should we pin only SPKI, or also names X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jeremy.rowley@digicert.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 19:39:21 -0000 There are a couple of groups, in addition to the CAB Forum, that may be interested in hosting a registrar. Let me check with them and get back to you. Many of those questions can be readily addressed once a group or once several groups have expressed a willingness to participate. The one that this working group is best poised to answer is whether the process details should be defined here or somewhere else. Jeremy -----Original Message----- From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Monday, August 12, 2013 12:50 PM To: Trevor Perrin Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names On Aug 12, 2013, at 7:11 PM, Trevor Perrin wrote: > On Mon, Aug 12, 2013 at 1:17 AM, Gervase Markham wrote: >> On 11/08/13 05:25, Trevor Perrin wrote: >>> Could we just say: >>> - The holder of a domain name is responsible for specifying the >>> SPKIs that it maps to. >>> - How the domain holder communicates this to the UA is out of scope. >> >> In other words "Don't set up a registry; just punt the problem and >> hope something works itself out organically"? > > Yes. > > If people hate this, someone should make a proposal for a registry: > > - Who maintains it? > - How are requests to add or remove CA names authenticated? > - Does the registry map CA names to actual keys? > - If so, how are change requests authenticated? > - What are the timing rules to ensure changes are propagated to > browsers as needed? > - How can the registry be monitored and double-checked to avoid it > becoming a single point of failure? > - Should these process details be defined in the HPKP spec or somewhere else? As you've said, before this is for the CAs and browsers to come up with such a solution (assuming they want it, and I'm not hearing this from either the Mozilla people or the Google people on this list). CAs and browers. Now, if only there was some forum where both of these come together... Joking aside, The CA/Browser forum is not currently in the business of running registries. IANA is, but I don't know how to specify in a draft an IANA policy that would include following mergers, acquisitions, and branding, and settling trademark disputes. Not do I have any reason to believe that IANA would be willing to do this. So unless the CA/Browser Forum agrees to take on this responsibility, and provide stable link for both machine and human readable mappings, I think this proposal should be shelved until we can find someone who will answer your questions above. Yoav _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec From jeremy.rowley@digicert.com Mon Aug 12 15:19:10 2013 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 58EC121F9F7A for ; Mon, 12 Aug 2013 15:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbsJsdVx5tv5 for ; Mon, 12 Aug 2013 15:19:06 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 2B84421F9EEE for ; Mon, 12 Aug 2013 15:19:06 -0700 (PDT) Received: from JROWLEYL1 (unknown [65.127.208.182]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 0E9067FA06C; Mon, 12 Aug 2013 16:19:05 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1376345945; bh=y0pRNcNNCwClDTvCFmVbQc7h1jySQhKCQ8exIkhJ5RI=; h=Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date; b=rjtFQq1Cxi2y0WXi80QXwGbKToopWskQmGs0ldLT7a3g7ukq7xdLrImixnBAEggle b8VlrldjHK4h1+hNSMVbsn2PlNCDO+oCpjXzY1Fo7isDTrBy0co/c6wBtjYW2ANYsc nwz/YK+vDuGLPH5hfJ3nOy5wbIRxOsKCEjrZ1kcM= From: "Jeremy Rowley" To: "'Rob Stradling'" , "'Yoav Nir'" References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <52089A35.9040103@mozilla.org> <053201ce9793$9a1dbd30$ce593790$@digicert.com> <52095DF1.80908@comodo.com> In-Reply-To: <52095DF1.80908@comodo.com> Date: Mon, 12 Aug 2013 16:19:05 -0600 Organization: DigiCert Message-ID: <057f01ce97a9$f5a76aa0$e0f63fe0$@digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJoJKS5/1/Jv2JXKWhm99jqPYGDVAJNKJejAdJQI9sCGoZA7wM5pAdUAiWKukcBIDPIBwNTr9QiAme7tNcCJlWFCwIOi6NMAkVqOGQBVDaKtgLV3uOul3ZA0aA= Content-Language: en-us Cc: 'websec' Subject: Re: [websec] #58: Should we pin only SPKI, or also names X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jeremy.rowley@digicert.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 22:19:10 -0000 As would DigiCert. Finding a home from the registry does not appear to be difficult if CA pinning is supported. Jeremy -----Original Message----- From: Rob Stradling [mailto:rob.stradling@comodo.com] Sent: Monday, August 12, 2013 4:13 PM To: jeremy.rowley@digicert.com; 'Yoav Nir' Cc: 'Trevor Perrin'; 'websec' Subject: Re: [websec] #58: Should we pin only SPKI, or also names Comodo would be happy to maintain this registry, if this WG decides that it's required. On 12/08/13 20:39, Jeremy Rowley wrote: > There are a couple of groups, in addition to the CAB Forum, that may > be interested in hosting a registrar. Let me check with them and get > back to you. > > Many of those questions can be readily addressed once a group or once > several groups have expressed a willingness to participate. The one > that this working group is best poised to answer is whether the > process details should be defined here or somewhere else. > > Jeremy > > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On > Behalf Of Yoav Nir > Sent: Monday, August 12, 2013 12:50 PM > To: Trevor Perrin > Cc: websec > Subject: Re: [websec] #58: Should we pin only SPKI, or also names > > > On Aug 12, 2013, at 7:11 PM, Trevor Perrin wrote: > >> On Mon, Aug 12, 2013 at 1:17 AM, Gervase Markham wrote: >>> On 11/08/13 05:25, Trevor Perrin wrote: >>>> Could we just say: >>>> - The holder of a domain name is responsible for specifying the >>>> SPKIs that it maps to. >>>> - How the domain holder communicates this to the UA is out of scope. >>> >>> In other words "Don't set up a registry; just punt the problem and >>> hope something works itself out organically"? >> >> Yes. >> >> If people hate this, someone should make a proposal for a registry: >> >> - Who maintains it? >> - How are requests to add or remove CA names authenticated? >> - Does the registry map CA names to actual keys? >> - If so, how are change requests authenticated? >> - What are the timing rules to ensure changes are propagated to >> browsers as needed? >> - How can the registry be monitored and double-checked to avoid it >> becoming a single point of failure? >> - Should these process details be defined in the HPKP spec or >> somewhere > else? > > As you've said, before this is for the CAs and browsers to come up > with such a solution (assuming they want it, and I'm not hearing this > from either the Mozilla people or the Google people on this list). CAs > and browers. Now, if only there was some forum where both of these come together... > > Joking aside, The CA/Browser forum is not currently in the business of > running registries. IANA is, but I don't know how to specify in a > draft an IANA policy that would include following mergers, > acquisitions, and branding, and settling trademark disputes. Not do I > have any reason to believe that IANA would be willing to do this. So > unless the CA/Browser Forum agrees to take on this responsibility, and > provide stable link for both machine and human readable mappings, I > think this proposal should be shelved until we can find someone who will answer your questions above. > > Yoav > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From rob.stradling@comodo.com Mon Aug 12 15:13:14 2013 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 EC4AB11E80E4 for ; Mon, 12 Aug 2013 15:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AY3DMpOi44sq for ; Mon, 12 Aug 2013 15:13:09 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9D08C11E80E0 for ; Mon, 12 Aug 2013 15:13:07 -0700 (PDT) Received: (qmail 9674 invoked from network); 12 Aug 2013 22:13:06 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 12 Aug 2013 22:13:06 -0000 Received: (qmail 4616 invoked by uid 1000); 12 Aug 2013 22:13:06 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Mon, 12 Aug 2013 23:13:06 +0100 Message-ID: <52095DF1.80908@comodo.com> Date: Mon, 12 Aug 2013 23:13:05 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: jeremy.rowley@digicert.com, 'Yoav Nir' References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <52089A35.9040103@mozilla.org> <053201ce9793$9a1dbd30$ce593790$@digicert.com> In-Reply-To: <053201ce9793$9a1dbd30$ce593790$@digicert.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 12 Aug 2013 15:29:07 -0700 Cc: 'websec' Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 12 Aug 2013 22:13:14 -0000 Comodo would be happy to maintain this registry, if this WG decides that it's required. On 12/08/13 20:39, Jeremy Rowley wrote: > There are a couple of groups, in addition to the CAB Forum, that may be > interested in hosting a registrar. Let me check with them and get back to > you. > > Many of those questions can be readily addressed once a group or once > several groups have expressed a willingness to participate. The one that > this working group is best poised to answer is whether the process details > should be defined here or somewhere else. > > Jeremy > > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf Of > Yoav Nir > Sent: Monday, August 12, 2013 12:50 PM > To: Trevor Perrin > Cc: websec > Subject: Re: [websec] #58: Should we pin only SPKI, or also names > > > On Aug 12, 2013, at 7:11 PM, Trevor Perrin wrote: > >> On Mon, Aug 12, 2013 at 1:17 AM, Gervase Markham wrote: >>> On 11/08/13 05:25, Trevor Perrin wrote: >>>> Could we just say: >>>> - The holder of a domain name is responsible for specifying the >>>> SPKIs that it maps to. >>>> - How the domain holder communicates this to the UA is out of scope. >>> >>> In other words "Don't set up a registry; just punt the problem and >>> hope something works itself out organically"? >> >> Yes. >> >> If people hate this, someone should make a proposal for a registry: >> >> - Who maintains it? >> - How are requests to add or remove CA names authenticated? >> - Does the registry map CA names to actual keys? >> - If so, how are change requests authenticated? >> - What are the timing rules to ensure changes are propagated to >> browsers as needed? >> - How can the registry be monitored and double-checked to avoid it >> becoming a single point of failure? >> - Should these process details be defined in the HPKP spec or somewhere > else? > > As you've said, before this is for the CAs and browsers to come up with such > a solution (assuming they want it, and I'm not hearing this from either the > Mozilla people or the Google people on this list). CAs and browers. Now, if > only there was some forum where both of these come together... > > Joking aside, The CA/Browser forum is not currently in the business of > running registries. IANA is, but I don't know how to specify in a draft an > IANA policy that would include following mergers, acquisitions, and > branding, and settling trademark disputes. Not do I have any reason to > believe that IANA would be willing to do this. So unless the CA/Browser > Forum agrees to take on this responsibility, and provide stable link for > both machine and human readable mappings, I think this proposal should be > shelved until we can find someone who will answer your questions above. > > Yoav > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From ryan-ietfhasmat@sleevi.com Mon Aug 12 15:53:43 2013 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 DE3EF21E8084 for ; Mon, 12 Aug 2013 15:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9l6rwwrhry9I for ; Mon, 12 Aug 2013 15:53:36 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 0211311E80E2 for ; Mon, 12 Aug 2013 15:53:26 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 5E83F36006D; Mon, 12 Aug 2013 15:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=zSms/Fu1HqQizhR2C4P8WfHZWYc=; b=OT4nm1rFpMM36pV6V zpv39wjYMew4Hw73LjfMZPOeo/Xa/Uawy/poCb2Cfr/nOCgjAkSbOtNn83M4v+2E 9k30fzMCOqJ3uVnooi4CLSpua3RhRde6bn/yfzb9OU7UgRLwAce4LQvWXrhdpA6X Zn2JJK1o1nCh138El2dJIJl4Q0= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPA id 2123B36006B; Mon, 12 Aug 2013 15:53:13 -0700 (PDT) Received: from 216.239.45.93 (proxying for 216.239.45.93) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Mon, 12 Aug 2013 15:53:13 -0700 Message-ID: In-Reply-To: <52091598.7000306@mozilla.org> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <52089A35.9040103@mozilla.org> <52091598.7000306@mozilla.org> Date: Mon, 12 Aug 2013 15:53:13 -0700 From: "Ryan Sleevi" To: "Gervase Markham" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 22:53:44 -0000 On Mon, August 12, 2013 10:04 am, Gervase Markham wrote: > On 12/08/13 17:11, Trevor Perrin wrote: > > If people hate this, someone should make a proposal for a registry: > > Or make a proposal to stick with the current spec, and not pin names := -) +1 to not pinning names. > > >> I think there will be problems with people not being protected who > >> expect to be, if you allow this sort of pinning into the spec but le= ave > >> entirely undefined the mechanisms for communicating what it actually > >> should mean when someone pins to a name. > > > > Could you explain how these problems would arise? > > > > I'm proposing CAs would coordinate with browsers, then inform their > > customers (websites) which name to use. A misbehaving CA could infor= m > > its customers of a meaningless name, causing browsers to ignore the > > pin. But a misbehaving CA could violate its customers' security in > > other ways. > > They would arise via any of the obvious mechanisms this could go wrong= , > e.g.: > > * CA fails to communicate with (some subset of) browsers, perhaps the > small ones, leading to divergent behaviour > > * Browser update is not universally accepted, leading to divergent > behaviour > > Say Foo CA merges with Bar CA, and issues an edict that from now on th= e > string "fooca.com" will include the already-deployed root, "Bar CA > Super-Secure". Six months later, after gnashing their teeth at the del= ay > that this process is introducing into their business, they start issui= ng > certs from "Bar CA Super-Secure" to Foo CA customers. A site, > naiveshop.com, is pinned to fooca.com, and buys one of these new certs= . > All naiveshop.com's customers whose browsers are older than 6 months g= et > connection failures, and naiveshop.com can't easily detect that this i= s > happening, or to how many people. > > Gerv To echo Gerv, I think there are a number of real and practical problems t= o the idea of pinning to names that make this even more error prone in practice than pinning to SPKIs. The most obvious one is how to distribute updates to names such that they are universally accepted/recognized? An SPKI is an unambiguous identifier= , but a named layer of indirection creates issues, especially if names are re-used (which is their whole value over SPKIs - is that they CAN be reused for different sets of pins over time). It's well known and understood that not every user updates their browser every cycle. Or, when and if pinning is integrated into an OS, they don't always update their OS. So you will quickly have a situation, very easily within a few releases, of the name 'Foo CA' ambiguously referring to multiple different sets of SPKIs. This is independent of mergers - CAs that are issuing new intermediates, or deprecating old roots, etc. You also create an assumption that "User Agent =3D=3D Root Store", which = is NOT a universal. There are a LARGE number of UAs (typically, smaller ones= ) that do not operate their own root store, and even one of the most popula= r UAs does not operate a root store across all their supported platforms. I= n this situation, roots may be added/removed from the root store on a time frame different from modifications to this proposed 'CA name list', thus creating interop issues like the one Gerv highlighted. Support for SPKI pinning relies on no other infrastructure - whether it b= e the registry or the update mechanisms - and can actively be shown to work in practice. The existing failure modes discussed in http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08#section-4 highlight the need to balance usability with security, and the trade-offs involved. Adding two or three more parties into the pinning infrastructure seems to trade security, add complexity, and not actually provide real benefit to usability, because it still allows pin skewing, but of a different nature= . To me, this represents a similar attempt to create another situation like the Public Suffix List ( http://publicsuffix.org/ ) - well intentioned, and certainly valuable, but easily opening up a whole host of new securit= y and deployment issues. From trevp@trevp.net Mon Aug 12 17:53:19 2013 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 0C3D821E8091 for ; Mon, 12 Aug 2013 17:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.715 X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ic+ALHkbT3tc for ; Mon, 12 Aug 2013 17:53:13 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id C238821E8090 for ; Mon, 12 Aug 2013 17:53:08 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id k13so5960656wgh.1 for ; Mon, 12 Aug 2013 17:53:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R/JTGrwjZTDIl6RpEIeF+HPTKtIrNRPk3P1q1lbtyOc=; b=ePrWY9J9lRhnp4Ty84dLYWq4MeE4waNVVcaFFi1dg0y8ucnAjkN7yPAPFzDGVMbC4Y Ap2wj3hQwb2SrZHbioE5HRFj1YHTGC7LIcIGY33gEQ3jDhH/n9z/vjJ9dsy2gsfDaUj6 dVH1vGDrGLwolZtzeZqqPYdXU2veZU1MIZG4UBamFVWeddh0gL8pJyH464S+HA6z51CG oXrvE9xVEzkdpifkJLy+BqNAwmlTIQJzXQf2DAi/6l/von77i0S7X5++73cTn18x5Xx1 MhZEuDb96vXcJvH29NDnUYgS9kHoP5C1GzqleX0w4RjGWtV+62XWHEt5rT9MB/GU2ziD a1jg== X-Gm-Message-State: ALoCoQnmYB/5VDP7J50xV6uqhNrK43LEvp3+j/wrBzAgSDx/MBmEyCvPsX5jcijgdXCdy9A2X7Dh MIME-Version: 1.0 X-Received: by 10.180.10.202 with SMTP id k10mr977415wib.17.1376355187760; Mon, 12 Aug 2013 17:53:07 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Mon, 12 Aug 2013 17:53:07 -0700 (PDT) X-Originating-IP: [50.37.31.184] In-Reply-To: <52091598.7000306@mozilla.org> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <52089A35.9040103@mozilla.org> <52091598.7000306@mozilla.org> Date: Mon, 12 Aug 2013 17:53:07 -0700 Message-ID: From: Trevor Perrin To: Gervase Markham Content-Type: text/plain; charset=ISO-8859-1 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 13 Aug 2013 00:53:19 -0000 On Mon, Aug 12, 2013 at 10:04 AM, Gervase Markham wrote: > On 12/08/13 17:11, Trevor Perrin wrote: >> If people hate this, someone should make a proposal for a registry: > > Or make a proposal to stick with the current spec, and not pin names :-) Sure. But then I'd also like to hear an argument for how this style of pinning could solve its usability problems and become widespread, given that Chrome's preloaded version of this attracted only 3 users in 27 months. >> Could you explain how these problems would arise? >> >> I'm proposing CAs would coordinate with browsers, then inform their >> customers (websites) which name to use. A misbehaving CA could inform >> its customers of a meaningless name, causing browsers to ignore the >> pin. But a misbehaving CA could violate its customers' security in >> other ways. > > They would arise via any of the obvious mechanisms this could go wrong, > e.g.: > > * CA fails to communicate with (some subset of) browsers, perhaps the > small ones, leading to divergent behaviour Well, either a popular CA communicates its key list to browsers, or it communicates it to the (thousands? millions?) of websites that would like to be pinned to that CA. There's a coordination problem either way. So pointing out that browser/CA coordination is a hassle and has some failure modes doesn't seem a compelling argument against it, given the alternatives. > * Browser update is not universally accepted, leading to divergent behaviour > > Say Foo CA merges with Bar CA, and issues an edict that from now on the > string "fooca.com" will include the already-deployed root, "Bar CA > Super-Secure". Six months later, after gnashing their teeth at the delay > that this process is introducing into their business, they start issuing > certs from "Bar CA Super-Secure" to Foo CA customers. A site, > naiveshop.com, is pinned to fooca.com, and buys one of these new certs. > All naiveshop.com's customers whose browsers are older than 6 months get > connection failures, and naiveshop.com can't easily detect that this is > happening, or to how many people. Coordination between browsers and CAs would have to involve timing rules. A browser who has not updated a name/key mapping after some period of time would have to stop using it, just as browsers stop using preloaded pins if they're too old. Trevor From jeremy.rowley@digicert.com Mon Aug 12 21:23:05 2013 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 A36EF21E80A6 for ; Mon, 12 Aug 2013 21:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQZ0S06u7Vwc for ; Mon, 12 Aug 2013 21:23:01 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id A0ED721E8093 for ; Mon, 12 Aug 2013 21:22:58 -0700 (PDT) Received: from JROWLEYL1 (unknown [12.165.222.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id C05307FA093; Mon, 12 Aug 2013 22:22:55 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1376367776; bh=cobzp3BbznU0gMTdmfKaXLeDKNbzbP9EthjgT0KzcU4=; h=Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date; b=zkp4SYYvW20HeWCHzBY9Our17zJMyxWvwVHeEn32nUvWqLKZMcc3T9hCXSxEJffel tzg/CNnjQYEtBn/7txiZjGPm0WaWK9CMDTiJFnxXeJILhr8gWMuz88GGQxyHX1lsEp JKeEsG8qNVDpIUlH+Nn5+kqY7ylbyCJt+nyFKGwM= From: "Jeremy Rowley" To: "'Trevor Perrin'" , "'Gervase Markham'" References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <52089A35.9040103@mozilla.org> <52091598.7000306@mozilla.org> In-Reply-To: Date: Mon, 12 Aug 2013 22:22:56 -0600 Organization: DigiCert Message-ID: <05e001ce97dc$c9d5bbb0$5d813310$@digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJoJKS5/1/Jv2JXKWhm99jqPYGDVAJNKJejAdJQI9sCGoZA7wM5pAdUAiWKukcBIDPIBwNTr9QiAme7tNcCJlWFCwIOi6NMAeW0QiMCcxkmuJeHWBRQ Content-Language: en-us Cc: 'websec' Subject: Re: [websec] #58: Should we pin only SPKI, or also names X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jeremy.rowley@digicert.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 04:23:05 -0000 The problems with pinning a CA are similar to problems with pinning a SPKI. Eventually, the browser needs updated pinned information. CA pinning shifts coordination of this update from the Website-Browser to a CA-Browser communication. Permitting CA pinning allows an entity to essentially delegate certificate decisions to single CA entity. The usability problems are somewhat resolved (although not eliminated) because the entity no longer needs to figure out exactly which keys should be pinned. Management can adopt a policy to only use fooCA and then pin that CA, eliminating the need to try and coordinate all the people responsible for making a decision and making the solution easier for management to understand than a presented set of SPKIs. Jeremy -----Original Message----- From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf Of Trevor Perrin Sent: Monday, August 12, 2013 6:53 PM To: Gervase Markham Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names On Mon, Aug 12, 2013 at 10:04 AM, Gervase Markham wrote: > On 12/08/13 17:11, Trevor Perrin wrote: >> If people hate this, someone should make a proposal for a registry: > > Or make a proposal to stick with the current spec, and not pin names > :-) Sure. But then I'd also like to hear an argument for how this style of pinning could solve its usability problems and become widespread, given that Chrome's preloaded version of this attracted only 3 users in 27 months. >> Could you explain how these problems would arise? >> >> I'm proposing CAs would coordinate with browsers, then inform their >> customers (websites) which name to use. A misbehaving CA could >> inform its customers of a meaningless name, causing browsers to >> ignore the pin. But a misbehaving CA could violate its customers' >> security in other ways. > > They would arise via any of the obvious mechanisms this could go > wrong, > e.g.: > > * CA fails to communicate with (some subset of) browsers, perhaps the > small ones, leading to divergent behaviour Well, either a popular CA communicates its key list to browsers, or it communicates it to the (thousands? millions?) of websites that would like to be pinned to that CA. There's a coordination problem either way. So pointing out that browser/CA coordination is a hassle and has some failure modes doesn't seem a compelling argument against it, given the alternatives. > * Browser update is not universally accepted, leading to divergent > behaviour > > Say Foo CA merges with Bar CA, and issues an edict that from now on > the string "fooca.com" will include the already-deployed root, "Bar CA > Super-Secure". Six months later, after gnashing their teeth at the > delay that this process is introducing into their business, they start > issuing certs from "Bar CA Super-Secure" to Foo CA customers. A site, > naiveshop.com, is pinned to fooca.com, and buys one of these new certs. > All naiveshop.com's customers whose browsers are older than 6 months > get connection failures, and naiveshop.com can't easily detect that > this is happening, or to how many people. Coordination between browsers and CAs would have to involve timing rules. A browser who has not updated a name/key mapping after some period of time would have to stop using it, just as browsers stop using preloaded pins if they're too old. Trevor _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec From trevp@trevp.net Mon Aug 12 23:40:42 2013 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 0203C11E80C5 for ; Mon, 12 Aug 2013 23:40:42 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFQg8-zKXXDz for ; Mon, 12 Aug 2013 23:40:37 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id E23FA21E809B for ; Mon, 12 Aug 2013 23:40:36 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id hq12so224384wib.14 for ; Mon, 12 Aug 2013 23:40:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6OAAbOOI6Rs1ynGDq/RAAcHnz+pqkTaGm+30dH46ciA=; b=jhZq30CWgzceBM+xl2E+cdDPZxlWgj4ATNWFdOeUBBqZ7ZZKZGfK7AdOad1ZO1PES2 AqOo+31qG4rtHshylDs55Q5+gW5FNzWVEff46ylnqpaFSBjfY9XaKD0Ue5P0FWG+If0V BOSxYNv6uPAkMsVrWEbDQ1C6aOKe/ErYomo5DFRGUNEtVHMQwQAlJQ30H+l5a2whazlO iTlHnPP7oGhJE/2j78BeBhDAqBU8V5XXPCkZGwFc5YoK+sKVUxn8csOiy0/2XcAegN0l SJDtdQ29Ts57ujyKYOBCE4NA2/qtn+ArfjmnZjy8/lHpysi3NgrPh2MKQ4xzuLllFVKm dJCA== X-Gm-Message-State: ALoCoQkOZ3246jG9S+swaTcx5Ydtv0e4OPEGNkqP9kdmcFHPXjo4hYvRh0+JzOTBZixJ2UNM0V4K MIME-Version: 1.0 X-Received: by 10.194.86.5 with SMTP id l5mr1811411wjz.19.1376376035713; Mon, 12 Aug 2013 23:40:35 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Mon, 12 Aug 2013 23:40:35 -0700 (PDT) X-Originating-IP: [166.137.187.101] In-Reply-To: References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <52089A35.9040103@mozilla.org> <52091598.7000306@mozilla.org> Date: Mon, 12 Aug 2013 23:40:35 -0700 Message-ID: From: Trevor Perrin To: ryan-ietfhasmat@sleevi.com Content-Type: text/plain; charset=ISO-8859-1 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 13 Aug 2013 06:40:42 -0000 On Mon, Aug 12, 2013 at 3:53 PM, Ryan Sleevi wrote: > > To echo Gerv, I think there are a number of real and practical problems to > the idea of pinning to names that make this even more error prone in > practice than pinning to SPKIs. > > The most obvious one is how to distribute updates to names such that they > are universally accepted/recognized? An SPKI is an unambiguous identifier, > but a named layer of indirection creates issues, especially if names are > re-used (which is their whole value over SPKIs - is that they CAN be > reused for different sets of pins over time). Names are also smaller, and easier to configure, review, and debug than lists of hash values. > It's well known and understood that not every user updates their browser > every cycle. Or, when and if pinning is integrated into an OS, they don't > always update their OS. So you will quickly have a situation, very easily > within a few releases, of the name 'Foo CA' ambiguously referring to > multiple different sets of SPKIs. Browsers would need to stop using name->key mappings that aren't current (say, more than 30 days old). > This is independent of mergers - CAs that are issuing new intermediates, > or deprecating old roots, etc. Yes, but either these get tracked by browsers, or they need to be tracked by every website using an affected CA pin. > You also create an assumption that "User Agent == Root Store", which is > NOT a universal. I wasn't assuming that. I was assuming CAs would publish key lists that are sufficient to work with all browsers and browser root stores. (They will need to do this regardless of whether these lists are used by websites for SPKI pins, or by browsers for named pins.) > There are a LARGE number of UAs (typically, smaller ones) > that do not operate their own root store, and even one of the most popular > UAs does not operate a root store across all their supported platforms. In > this situation, roots may be added/removed from the root store on a time > frame different from modifications to this proposed 'CA name list', thus > creating interop issues like the one Gerv highlighted. If a website is publishing SPKI pins, it will have to deal with the complexities of varying browser root stores and path construction by itself. I.e., the website will have to publish an HPKP header that takes into account all possible certificate paths all browser might construct for all certs it might use during the pin lifetime. This is complexity intrinsic to trying to pin cert chains. It's not caused by named pins. But with named pins, we could move this complexity from being an issue for website deployers to an issue for browser/CA coordination, who are better equipped to handle it. This seems like an argument *for* named pins, rather than against it. > Support for SPKI pinning relies on no other infrastructure - whether it be > the registry or the update mechanisms - and can actively be shown to work > in practice. The existing failure modes discussed in > http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08#section-4 > highlight the need to balance usability with security, and the trade-offs > involved. > > Adding two or three more parties into the pinning infrastructure seems to > trade security, add complexity, and not actually provide real benefit to > usability, because it still allows pin skewing, but of a different nature. I think the usability benefit of having a mostly-static HPKP header listing a few well-known brand names vs. a fluctuating list of many key hashes, determined by factors most websites don't understand and have little visibility into, is pretty obvious. I could imagine the former becoming widely used. Websites could easily see what other websites are doing, discuss and compare which CAs they consider good choices, and test and review their deployments. CAs would be incentivized to opt-in to this system by making it easy for browsers to pin them, and to provide good security so that websites would choose to include them into pins. I could plausibly imagine it becoming a best-practice for websites to do CA pinning, even if it's fairly broad pins to sets of popular CAs. I have trouble imagining this level of adoption with HPKP in its current form. Trevor From trevp@trevp.net Mon Aug 12 23:43:23 2013 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 E126921E80B9 for ; Mon, 12 Aug 2013 23:43:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giOcWyfmnBtx for ; Mon, 12 Aug 2013 23:43:18 -0700 (PDT) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ietfa.amsl.com (Postfix) with ESMTP id D203F11E80C5 for ; Mon, 12 Aug 2013 23:43:17 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u57so6111340wes.23 for ; Mon, 12 Aug 2013 23:43:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dbKHvS63ORdxpZ914McCnevb6cpQg6aovqy74SqiQG8=; b=HOR8RA/Q5aAPHAalWsLbbGW/ily9dpJQie2a+SxiRNneM7p4CkAnGUSQ2iQLIiyyLX YYFAqBtTKtj2YvFD23bfEVfekHXNyQhwv9lpNrtg77WvjHGR0i9jBr7oeG5r9ZbKrKXq Q+otDgLmo6HczEe0lvyuPz6VwSRacI0SItpjNv8ZlVrfbqNd8GjBwlX6Eh0eKr5rdEbJ Sv/+3E4RanF+9VK35qVcMIQfcC+yRpXQui0jy72dObxRE6QFXY1+6slF5SOHJmTOMQAD TkOvPn9x/LEFK2jLKywmd63kLl1e4nDF0RA4KLh4eWHaU6NbRdySMF7d+b1IBlP8egk0 V2MA== X-Gm-Message-State: ALoCoQlf2VzC8xm6r53m8IM2rulOoSaKPe7OBHRB6FKGV4hnUcXaZY9ry2SlpV50hM+9+bf7R/mA MIME-Version: 1.0 X-Received: by 10.180.205.236 with SMTP id lj12mr1379005wic.22.1376376196948; Mon, 12 Aug 2013 23:43:16 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Mon, 12 Aug 2013 23:43:16 -0700 (PDT) X-Originating-IP: [166.137.187.101] In-Reply-To: <05e001ce97dc$c9d5bbb0$5d813310$@digicert.com> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <52089A35.9040103@mozilla.org> <52091598.7000306@mozilla.org> <05e001ce97dc$c9d5bbb0$5d813310$@digicert.com> Date: Mon, 12 Aug 2013 23:43:16 -0700 Message-ID: From: Trevor Perrin To: jeremy.rowley@digicert.com Content-Type: text/plain; charset=ISO-8859-1 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 13 Aug 2013 06:43:24 -0000 On Mon, Aug 12, 2013 at 9:22 PM, Jeremy Rowley wrote: > The problems with pinning a CA are similar to problems with pinning a SPKI. > Eventually, the browser needs updated pinned information. CA pinning shifts > coordination of this update from the Website-Browser to a CA-Browser > communication. > > Permitting CA pinning allows an entity to essentially delegate certificate > decisions to single CA entity. Or multiple CAs. I think many sites would be well-served by pinning to several CAs. This would yield a very safe pin with minimal vendor lock-in and with protection from catastrophes like a CA being delisted or going out of business. With SPKI pinning, this multiplies the size of the HPKP header and the number of CA key lists the site has to track. That's a big reason I'm pushing for a more manageable approach. Trevor From gerv@mozilla.org Tue Aug 13 02:43:02 2013 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 6A4D021E80F4 for ; Tue, 13 Aug 2013 02:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wG-8Mec1oFMm for ; Tue, 13 Aug 2013 02:42:56 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3A821E80F8 for ; Tue, 13 Aug 2013 02:42:54 -0700 (PDT) Received: from [192.168.0.101] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id AEEE2F2262; Tue, 13 Aug 2013 02:42:52 -0700 (PDT) Message-ID: <5209FF9D.1080208@mozilla.org> Date: Tue, 13 Aug 2013 10:42:53 +0100 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Trevor Perrin References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <52089A35.9040103@mozilla.org> <52091598.7000306@mozilla.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 13 Aug 2013 09:43:02 -0000 On 13/08/13 07:40, Trevor Perrin wrote: > Names are also smaller, and easier to configure, review, and debug > than lists of hash values. Sure. No-one is denying that there are some advantages to using names; the question is whether those advantages are worth it given the significant downsides. In terms of how to proceed, I suggest the wise thing is to define the syntax so it is open to being extended with names or other identifiers later, but get the standard done without that facility. Then, we don't have to let the best be the enemy of the good. >> It's well known and understood that not every user updates their browser >> every cycle. Or, when and if pinning is integrated into an OS, they don't >> always update their OS. So you will quickly have a situation, very easily >> within a few releases, of the name 'Foo CA' ambiguously referring to >> multiple different sets of SPKIs. > > Browsers would need to stop using name->key mappings that aren't > current (say, more than 30 days old). And so HPKP no longer works for those sites in those browsers? That doesn't sound great from a security standpoint to me. It also makes using names clearly worse for the site than using hashes. That's rather a big change in the idea to be throwing in as a bullet point mid-way through a discussion. Forgive me, but it rather seems like you are making this up as you go along rather than having thought it through and presented a coherent proposal. >> This is independent of mergers - CAs that are issuing new intermediates, >> or deprecating old roots, etc. > > Yes, but either these get tracked by browsers, or they need to be > tracked by every website using an affected CA pin. If the idea of using names is greater simplicity for sites, imposing a requirement that they track the goings-on in the CA industry seems not to meet that goal. > I could imagine the former becoming widely used. Websites could > easily see what other websites are doing, discuss and compare which > CAs they consider good choices, and test and review their deployments. > CAs would be incentivized to opt-in to this system by making it easy > for browsers to pin them, and to provide good security so that > websites would choose to include them into pins. Can't CA's help in the current system? "Here's the set of 3 opaque strings you should add to your HPKP header to pin to our consumer roots" is not all that much more complex than "Here's a string that looks like a domain name you should add to your HPKP header to pin to our consumer roots". Gerv From spencerdawkins.ietf@gmail.com Mon Aug 12 18:10:12 2013 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 E0B5611E80FC; Mon, 12 Aug 2013 18:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXc9CuP4HddA; Mon, 12 Aug 2013 18:10:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 947D811E80E9; Mon, 12 Aug 2013 18:10:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Spencer Dawkins" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130813011010.13384.75933.idtracker@ietfa.amsl.com> Date: Mon, 12 Aug 2013 18:10:10 -0700 X-Mailman-Approved-At: Tue, 13 Aug 2013 04:32:57 -0700 Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, websec-chairs@tools.ietf.org Subject: [websec] Spencer Dawkins' No Objection on draft-ietf-websec-x-frame-options-08: (with COMMENT) 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, 13 Aug 2013 01:10:12 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-websec-x-frame-options-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I really like this specification, and I appreciate the working group producing it. Documenting "in the wild" behavior is a good thing. I have one fairly fundamental comment, which I think can be easily addressed, and a few nits. My comment: This specification starts out like a normal header field specification until you get to = 1. Introduction This specification provides informational documentation about the current use and definition of the X-Frame-Options HTTP header field. Given that the "X-" construction is deprecated [RFC6648], the X -Frame-Options header field will in the future be replaced by the Frame-Options directive in the Content Security Policy Version 1.1 [CSP-1-1]. = That's still KIND of OK (no indication that anything is wrong with X-FRAME-OPTIONS functionality, just a heads-up that implementations that include X-FRAME-OPTIONS will have work to do in the future), but when we get to = 2.3.2.2. Variation in current browser behaviour There are currently variations in the implementation of the X-FRAME- OPTIONS header. = we discover unambiguously that current implmentations don't all work the same way, so your ability to rely on X-FRAME-OPTIONS is not entirely clear. I wonder if the set of technical details are asperational, saying "this is what X-FRAME-OPTIONS could have been, and what the next header field in this space should be". I think it's fine to publish this specification, especially as Informational, even if it's not clear to me that *any* of the functionality described in this specification is implemented the same way in all major browsers. I would be more comfortable with a clear statement in the Introduction that the biggest problem with X-FRAME-OPTIONS is *not* the leading "X-", but that today's implementations don't all provide the same options with the same behaviors, so relying on this specification as a predictor of what will happen to your frames is not a good idea. = One sentence that puts the reader on notice would be sufficient. My nits, just so editors don't have to find them again: Is there a reason why sometimes X-FRAME-OPTIONS is in all caps, and other times not? I'm not an APP guy, so I'm asking. In Section 2.3.2.2. Variation in current browser behaviour These variations in the evaluation of the header by different implementations impair the useage and reliability of this http header. A revised version of x-frame-options in the form of a frame- options directive in the CSP 1.1[CSP-1-1] will unify the behaviour and it is expected that newer implementations will use it rather than the mechanisms documented here" The trailing quote mark should be a period, I suppose? 5.1. Privacy Considreations should be "Considerations". In B.2. Online Shop Confirm Purchase Page The "Confirm Purchase"" = The doubled trailing quote marks should be one quote mark, perhaps? From tobias.gondrom@gondrom.org Tue Aug 13 09:47:49 2013 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 34EC011E8191 for ; Tue, 13 Aug 2013 09:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGjU5ihuJG40 for ; Tue, 13 Aug 2013 09:47:44 -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 39A8911E8189 for ; Tue, 13 Aug 2013 09:47:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=nMriRTYEe1Ho++a2AKw93CsC13tAsJPzSWBzZtu9J3gaw3aggRXAN/pbHO7NeguGSjH+h0H5gvrmSfRaC4aRS13+fhGtcHKwma02SFDwULo+YQmhgr7T45+DMVwtCsOR; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 5150 invoked from network); 13 Aug 2013 18:47:32 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.64?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 13 Aug 2013 18:47:32 +0200 Message-ID: <520A6324.4050104@gondrom.org> Date: Tue, 13 Aug 2013 17:47:32 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: spencerdawkins.ietf@gmail.com References: <20130813011010.13384.75933.idtracker@ietfa.amsl.com> In-Reply-To: <20130813011010.13384.75933.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, iesg@ietf.org, websec-chairs@tools.ietf.org Subject: Re: [websec] Spencer Dawkins' No Objection on draft-ietf-websec-x-frame-options-08: (with COMMENT) 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, 13 Aug 2013 16:47:49 -0000 Dear Spencer, thanks a lot for the review and feedback. I included your feedback comments in version-09. Thanks for the review and all the best, Tobias On 13/08/13 02:10, Spencer Dawkins wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-websec-x-frame-options-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I really like this specification, and I appreciate the working group > producing it. Documenting "in the wild" behavior is a good thing. > > I have one fairly fundamental comment, which I think can be easily > addressed, and a few nits. > > My comment: This specification starts out like a normal header field > specification until you get to > > 1. Introduction > > This specification provides informational documentation about the > current use and definition of the X-Frame-Options HTTP header field. > Given that the "X-" construction is deprecated [RFC6648], the X > -Frame-Options header field will in the future be replaced by the > Frame-Options directive in the Content Security Policy Version 1.1 > [CSP-1-1]. > > That's still KIND of OK (no indication that anything is wrong with > X-FRAME-OPTIONS functionality, just a heads-up that implementations that > include X-FRAME-OPTIONS will have work to do in the future), but when we > get to > > 2.3.2.2. Variation in current browser behaviour > > There are currently variations in the implementation of the X-FRAME- > OPTIONS header. > > we discover unambiguously that current implmentations don't all work the > same way, so your ability to rely on X-FRAME-OPTIONS is not entirely > clear. > > I wonder if the set of technical details are asperational, saying "this > is what X-FRAME-OPTIONS could have been, and what the next header field > in this space should be". > > I think it's fine to publish this specification, especially as > Informational, even if it's not clear to me that *any* of the > functionality described in this specification is implemented the same way > in all major browsers. > > I would be more comfortable with a clear statement in the Introduction > that the biggest problem with X-FRAME-OPTIONS is *not* the leading "X-", > but that today's implementations don't all provide the same options with > the same behaviors, so relying on this specification as a predictor of > what will happen to your frames is not a good idea. > > One sentence that puts the reader on notice would be sufficient. Done. > My nits, just so editors don't have to find them again: > > Is there a reason why sometimes X-FRAME-OPTIONS is in all caps, and other > times not? I'm not an APP guy, so I'm asking. Only reason is that my eyes got tired of so many all caps in the flow text, while in some place, I felt it would be easier to read when in all caps. Both are possible. > > In Section 2.3.2.2. Variation in current browser behaviour > > These variations in the evaluation of the header by different > implementations impair the useage and reliability of this http > header. A revised version of x-frame-options in the form of a frame- > options directive in the CSP 1.1[CSP-1-1] will unify the behaviour > and it is expected that newer implementations will use it rather than > the mechanisms documented here" > > The trailing quote mark should be a period, I suppose? Yes. Corrected. > > 5.1. Privacy Considreations should be "Considerations". Thanks. Corrected. > > In B.2. Online Shop Confirm Purchase Page > > The "Confirm Purchase"" > > The doubled trailing quote marks should be one quote mark, perhaps? Yes. Thanks. Corrected. > From internet-drafts@ietf.org Tue Aug 13 09:48:18 2013 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 CD60211E81A4; Tue, 13 Aug 2013 09:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZE9AkaAKMrK1; Tue, 13 Aug 2013 09:48:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A6B11E81AB; Tue, 13 Aug 2013 09:48:17 -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.70.p1 Message-ID: <20130813164817.26226.95459.idtracker@ietfa.amsl.com> Date: Tue, 13 Aug 2013 09:48:17 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-x-frame-options-09.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: Tue, 13 Aug 2013 16:48:18 -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 Header Field X-Frame-Options Author(s) : David Ross Tobias Gondrom Filename : draft-ietf-websec-x-frame-options-09.txt Pages : 12 Date : 2013-08-13 Abstract: To improve the protection of web applications against Clickjacking, this definition describes the X-Frame-Options HTTP response header field that declares a policy communicated from the server to the client browser on whether the browser may display the transmitted content in frames that are part of other web pages. This informational document serves to document the existing use and specification of this X-Frame-Options HTTP response header field. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-x-frame-options-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Aug 13 09:48:19 2013 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 E9D1B11E81AC for ; Tue, 13 Aug 2013 09:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUL-cpKs3gZt; Tue, 13 Aug 2013 09:48:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEC911E81B1; Tue, 13 Aug 2013 09:48:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: websec-chairs@tools.ietf.org, draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130813164817.26226.5272.idtracker@ietfa.amsl.com> Date: Tue, 13 Aug 2013 09:48:17 -0700 Subject: [websec] New Version Notification - draft-ietf-websec-x-frame-options-09.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: Tue, 13 Aug 2013 16:48:20 -0000 A new version (-09) has been submitted for draft-ietf-websec-x-frame-option= s: http://www.ietf.org/internet-drafts/draft-ietf-websec-x-frame-options-09.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-x-frame-options-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From ietf-secretariat-reply@ietf.org Tue Aug 13 09:55:28 2013 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 B5CA611E8184 for ; Tue, 13 Aug 2013 09:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qI4Zsg974EA; Tue, 13 Aug 2013 09:55:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D233411E81AA; Tue, 13 Aug 2013 09:55:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: websec-chairs@tools.ietf.org, draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130813165513.11045.17385.idtracker@ietfa.amsl.com> Date: Tue, 13 Aug 2013 09:55:13 -0700 From: IETF Secretariat X-Mailman-Approved-At: Tue, 13 Aug 2013 10:08:01 -0700 Subject: [websec] ID Tracker State Update Notice: 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, 13 Aug 2013 16:55:28 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-o= ptions/ From rjsparks@nostrum.com Tue Aug 13 14:34:40 2013 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 307EA21F8F4A; Tue, 13 Aug 2013 14:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izCVaDFEO-8U; Tue, 13 Aug 2013 14:34:39 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2173121F8D90; Tue, 13 Aug 2013 14:34:36 -0700 (PDT) Received: from unnumerable.local (pool-173-71-53-173.dllstx.fios.verizon.net [173.71.53.173]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r7DLYTHx015954 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Tue, 13 Aug 2013 16:34:29 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <520AA664.2080208@nostrum.com> Date: Tue, 13 Aug 2013 16:34:28 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jari Arkko References: <5203F8C2.3060807@nostrum.com> <5207F83D.9010207@gondrom.org> <00E6E44C-78D7-4FEA-A540-72AFA12E0D81@piuha.net> In-Reply-To: <00E6E44C-78D7-4FEA-A540-72AFA12E0D81@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 173.71.53.173 is authenticated by a trusted mechanism) Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, gen-art@ietf.org, websec@ietf.org Subject: Re: [websec] [Gen-art] Genart LC review: draft-ietf-websec-x-frame-options-07 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, 13 Aug 2013 21:34:40 -0000 Copying websec at Barry's request: On 8/13/13 2:52 PM, Jari Arkko wrote: > Robert: Thank you very much for your review. This has been very helpful. Tobias: Thank you for the changes. > > (I can see that there could be some discussion about some of the remaining text changes. Do you Robert think the remaining points are important enough to warrant me raising them in the IESG discussion? For now I have filed a No-Objection position.) Thanks for the nudge Jari. I've continued the conversation below. I would still like to see some adjustment of the character of the text, but if I were a balloting AD, I would be putting in comments, not discusses. Tobias - Thanks for your changes so far. I appreciate that some of what I'm pushing for may seem subtle. I've had to handle several documents that might have been standardization fodder at some point in time but for various reasons turned out not to be. The resulting documentation of some of those came out looking to me like a standards document with an Informational or Independent Submission label taped to the top. You've done a good job of avoiding that with this document, and the changes I'm pushing for are to make that aspect even better (I hope). Thank you (and the WG) for considering them. > > Jari > > On Aug 12, 2013, at 4:46 AM, Tobias Gondrom wrote: > >> Dear Robert, >> >> thank you very much for the review. >> I revised the document to version-08 (also including feedback from other >> reviews) accordingly including most of your feedback. >> Answers inline. >> Best regards, Tobias >> >> >> On 08/08/13 21:00, Robert Sparks wrote: >>> I am the assigned Gen-ART reviewer for this draft. For background on >>> Gen-ART, please see the FAQ at >>> >>> . >>> >>> Please resolve these comments along with any other Last Call comments >>> you may receive. >>> >>> Document: draft-ietf-websec-x-frame-options-07 >>> Reviewer: Robert Sparks >>> Review Date: 2013-08-08 >>> IETF LC End Date: 2013-08-12 >>> IESG Telechat date: 2013-08-15 >>> >>> Summary: This draft is basically ready for publication, but has nits >>> that should be fixed before publication. >>> >>> This document is intended to act as a informational reference >>> describing what's already deployed, and not to act as a standard for >>> new implementations to follow. It's obvious that some care has been >>> taken to keep that tone in the text, but there are places where it >>> still looks like a proposed standard. Please make it even more clear >>> who the audience for this document is, and look for places to >>> reinforce that this is documenting what _is_, as opposed to trying to >>> influence what should be. >>> >>> The introduction of this version of the document does a good job of >>> describing what a clickjack attack is. Appendix B is not really adding >>> to that description. I suggest that the two usecases it call out be >>> reduced to a couple of sentences in the introduction as examples, and >>> a reference to a more in-depth treatment of scenarios like them be >>> added for those looking for more information. Section B.3 is >>> different, and doesn't add to the understanding of this document. >>> Again, I suggest pointing to somewhere else that provides an in-depth >>> treatment. (Hopefully, that source would discuss the nested frame >>> issue the security considerations section points out in the context of >>> the this specific configuration page). [FRAME-BUSTING] might be >>> enough, but pointers to something even more rich would certainly be >>> helpful. >> Apologies, but I would rather keep the three example cases in the >> appendix of the document as this will allow better understanding of the >> document if references are no longer available. I don't think they do, actually. If those references are gone, there is not enough in this document, particularly in those appendices, to inform someone who didn't already understand clickjacking. To state that more strongly, I don't think you're helping the type of future reading you are trying to help, and as a consequence, you may even add to their confusion. I don't think adding more to this document is the right thing to do. I really think you should point to references instead. If you don't trust the ones you have to be stable for the period of time this document is needed (which surprises me), then perhaps you should look for something more stable? >> Consider that >> clickjacking description references are not IETF, nor other SDOs and >> potentially not stable over the full lifecycle of the RFC. >> >> >> >>> Here are some suggestions in document order: >>> >>> In the Abstract, I suggest replace "specification" with either >>> "definition" as the introduction uses, or with "the syntax and >>> behavior observed in current deployments". >> Ok. changed to "definition". I wasn't specific with which instance of specification I meant (I missed that there were two). With the new text (-09), in this paragraph, I would say "this document describes" instead of "this definition describes", and "definition of this X-Frame-Options" rather than "specification of this X-Frame-Options". >> >> >>> The last paragraph of the introduction reads like standards text. >>> Please consider rewriting it with a tone of history and current fact. >>> Perhaps starting with "In existing implementations, ", and replacing >>> the last sentence with something like "The policy this HTTP header >>> declares is enforced by the browser implementations documented here". >> Changed accordingly. >> Please note: IMHO I did not feel that the last paragraph of the >> introduction reads like standards text. However, I appreciate your >> feedback and did modify the last sentence of the last paragraph of the >> introduction accordingly to remove the word "conforming". >> (I believe the remaining text describes sufficiently that this is >> documentation. So I did not want to rewrite the whole paragraph and add >> history.) Thanks for those edits, and the ones you call out below. >> >> >>> Since this is documenting an existing deployed header (not >>> standardizing it), it would be useful to comment whether the existing >>> known implementations allow all the productions of the ABNF described >>> here to be used. For instance, would they all honor X-FRAME-OPTIONS: >>> deny? (While thinking about this, focus on who this document is for.) >> Please note, that section 2.3.2.2. describes the variation in behaviour >> between different browsers. >> As existing browser implementations may change with regards to whether >> they allow _all_ the productions of the ABNF, we intentionally did not >> investigate and document all possible outcomes and combinations. >> >>> The last sentence of 2.3.1 as written is an attempt to be a standard, >>> and is an odd use of 2119. I suggest rewriting it as a warning about >>> what happens with existing plugins that ignore the policy carrid in >>> the header. That keeps the message aligned with documenting what exists. >> Ok. I changed it to non-2119. >> However, the remaining text is appropriate and adds clarity to declare >> the scope of the x-frame-options header effects. And implementations and >> specifications of x-frame-options out there consider it as part that >> plug-ins observe x-frame-options if "these plugins appear essentially as >> frames". >> Please consider that a plug-in that would "essentially appear as a >> frame" but would not be observing x-frame-options would in effect break >> the security model of the browser implementation, so I think the >> remaining text is appropriate and needed in this case. This takes you into talking about what new implementations should do, rather than documenting what's in the wild. You can avoid that by noting that any existing plug-in implementations that don't do the right thing here create a problem. (It would follow that any new ones would have that same problem). >> >> >>> The first sentence of 2.3.2 is not adding anything to the document. I >>> suggest deleting it. The second sentence is placing an implementation >>> requirement again. Please consider rewriting as an observation of what >>> existing things do, calling out the ramifications of the ones that >>> behave differently. >> Please consider that even though this is to document existing use >> (especially until we get CSP1.1), it's documentation can also help guide >> new implementations for the purpose to reduce or avoid divergence of >> implementations. You can have that influence by reporting on what is rather than trying to write constraints on new things. >> This leads to the first sentence and also to the use of >> "MAY" in the second sentence, which in fact is not a requirement of the >> browser implementation but points out an implementation option. >> >>> Similarly, the first paragraphs of Section 2.3.2.1 is written to >>> affect new implementation, not document existing implementation. They >>> could be re-tuned as above. The third paragraph is good history >> As the comment before, this documentation also helps to reduce or avoid >> divergence of implementations. So the "SHOULD" is appropriate and as >> intended here. How about simply saying that any change or divergence to the implementations will result in (this list of bad things). That's informative rather than trying to be normative. >> >> >>> The last sentence of 2.3.2.2 should not say "replace this document" - >>> this document is informational documentation about existing >>> deployments. CSP1.1 won't Obsolete or Replace this document. Rather it >>> should say something like "it is expected that newer implementations >>> will use it rather than the mechanisms documented here". >> Ok. Changed accordingly. >> >>> Nit: s/does support only one/only supports one/ >> Ok. Changed. >>> Do the known implementations follow the pattern described in 2.3.2.3? >>> Saying something would help tie this to being information about the >>> known deployment rather than trying to constrain new development. >> Hm. First, as outlined in 2.3.2.2 not all of the browsers support >> "Allow-From". And second, the pattern is actually not for the browser >> but a way for the server to achieve the specific goal (i.e. of a source >> page being framed by more than one web page, even though allow-from >> supports only on URI). >> To accomodate your feedback and make clear this is not trying to >> contrain new development, I changed the word "is recommended" to "can >> fulfill that need". >> >>> Nit: If Appendix B is kept, please expand CSRF (and consider >>> re-pointing to a reference) >>> >> Ok. Done. >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art From turners@ieca.com Wed Aug 14 09:14:46 2013 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 8EF7D21F9B80; Wed, 14 Aug 2013 09:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+6ARqCj-vfs; Wed, 14 Aug 2013 09:14:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2078321F9B5F; Wed, 14 Aug 2013 09:14:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Sean Turner" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130814161444.6218.82572.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2013 09:14:44 -0700 Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, websec-chairs@tools.ietf.org Subject: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 14 Aug 2013 16:14:46 -0000 Sean Turner has entered the following ballot position for draft-ietf-websec-x-frame-options-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- It's interesting to note that this draft says there's a problem with folks not checking the origins of the entire ancestor tree of names of the framing resource - but then doesn't say that sounds like a good idea do it. I can see the argument that might be made that this draft is just documenting what's done now, but shouldn't we take the opportunity to do more and recommend something along the lines of "The entire ancestor tree of names of the framing resource SHOULD be checked to mitigate the risk of attacks in multiple-nested scenarios" or something like that? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'd ask about how RFC 6648 applies to this, but I bet this header was out long before the drafts that lead to RFC 6648. s1 (penultimate paragraph): r/script/Javascript ? s4.1: Is Figure 1 missing or is that the registration template? ;) s5: r/all kinds of these attack vectors/these kind of attack vectors r/, ...)/) Appendix A: Is this a guarantee that x-frame-options/frame-options will be supported henceforth until the end of time in those browsers? = Basically, I'm not sure Appendix A is needed. From barryleiba@gmail.com Wed Aug 14 09:30:20 2013 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 B47D321F93FB; Wed, 14 Aug 2013 09:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.895 X-Spam-Level: X-Spam-Status: No, score=-101.895 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGALgVW6Cqe1; Wed, 14 Aug 2013 09:30:20 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 353B321E808C; Wed, 14 Aug 2013 09:30:18 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id s1so5034300qcw.9 for ; Wed, 14 Aug 2013 09:30:17 -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:message-id:subject :from:to:cc:content-type; bh=w7UVLCwfgM520LQ7Y2hBV9gkFY2SMw7Rd8eePlK61A4=; b=wkcmQjkcZZZZJaF9+AhZ7PY8pym3oKzHwEvFapw6/3S/fLKFLCelTJAnpZl2GhTRfv 7muC+bA6JOIXFvrA/56ml07VgW/lGRd5q0Ma5BPLa+/q9HTsTi7BZUc/XVot0q0qQajK QA05vNZJIHg89pygFGEcriHKssXCx6/06VXqtgqiLmCziK1UmMREZ+zpCmZ7jdCOKPgG Kgj1012UQYdLMHuqv7/H/f8caGHdpDszX+60O9u3IC/Jttqmned/ju4MbM38VBKL5GNM yGScp7w5f+jovVeAXsV7ZxYgHqn9l/t590QshqJvlyvPaQkC1ckHk6banfw9djmWftqY qpyA== MIME-Version: 1.0 X-Received: by 10.224.97.66 with SMTP id k2mr3424259qan.109.1376497817470; Wed, 14 Aug 2013 09:30:17 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.59.211 with HTTP; Wed, 14 Aug 2013 09:30:17 -0700 (PDT) In-Reply-To: <20130814161444.6218.82572.idtracker@ietfa.amsl.com> References: <20130814161444.6218.82572.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2013 18:30:17 +0200 X-Google-Sender-Auth: zB66kzN8ESX07LZaGl1HLh-r5EM Message-ID: From: Barry Leiba To: Sean Turner Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , websec@ietf.org, The IESG , "websec-chairs@tools.ietf.org" Subject: Re: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 14 Aug 2013 16:30:20 -0000 > It's interesting to note that this draft says there's a problem with > folks not checking the origins of the entire ancestor tree of names of > the framing resource - but then doesn't say that sounds like a good idea > do it. I can see the argument that might be made that this draft is just > documenting what's done now, but shouldn't we take the opportunity to do > more and recommend something along the lines of "The entire ancestor tree > of names of the framing resource SHOULD be checked to mitigate the risk > of attacks in multiple-nested scenarios" or something like that? It seems that that should be work for the W3C folks who are working on the successor mechanism. This really *is* just meaning to document what's in use now, warts and all. Barry From tobias.gondrom@gondrom.org Wed Aug 14 09:42:05 2013 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 7576711E818E for ; Wed, 14 Aug 2013 09:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.361 X-Spam-Level: X-Spam-Status: No, score=-95.361 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0y+cMj1xhxn for ; Wed, 14 Aug 2013 09:41:42 -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 08CD711E8159 for ; Wed, 14 Aug 2013 09:41:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=XsERHuS7GHVEOy+xnONmYUqx5C5uIzExejWkRAsaecmybBzK+fYWXeOD9KVWtvXnFcGa5VHALOKb6x9HLyIIpzYAe239mn3uTr3kqbAsdZ6RGjKk7KwpeVp2L4zag+4+; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 16072 invoked from network); 14 Aug 2013 18:41:38 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.64?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 14 Aug 2013 18:41:38 +0200 Message-ID: <520BB341.3050209@gondrom.org> Date: Wed, 14 Aug 2013 17:41:37 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: barryleiba@computer.org, turners@ieca.com References: <20130814161444.6218.82572.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------070303030209030104070701" Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, iesg@ietf.org, websec-chairs@tools.ietf.org Subject: Re: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 14 Aug 2013 16:42:05 -0000 This is a multi-part message in MIME format. --------------070303030209030104070701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 14/08/13 17:30, Barry Leiba wrote: >> It's interesting to note that this draft says there's a problem with >> folks not checking the origins of the entire ancestor tree of names of >> the framing resource - but then doesn't say that sounds like a good idea >> do it. I can see the argument that might be made that this draft is just >> documenting what's done now, but shouldn't we take the opportunity to do >> more and recommend something along the lines of "The entire ancestor tree >> of names of the framing resource SHOULD be checked to mitigate the risk >> of attacks in multiple-nested scenarios" or something like that? > It seems that that should be work for the W3C folks who are working on > the successor mechanism. This really *is* just meaning to document > what's in use now, warts and all. > > Barry I agree with Barry. (And we gave according input to WebAppSec at W3C when we handed over the goal for CSP1.1.) Best regards, Tobias --------------070303030209030104070701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 14/08/13 17:30, Barry Leiba wrote:
It's interesting to note that this draft says there's a problem with
folks not checking the origins of the entire ancestor tree of names of
the framing resource - but then doesn't say that sounds like a good idea
do it.  I can see the argument that might be made that this draft is just
documenting what's done now, but shouldn't we take the opportunity to do
more and recommend something along the lines of "The entire ancestor tree
of names of the framing resource SHOULD be checked to mitigate the risk
of attacks in multiple-nested scenarios" or something like that?

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

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

Best regards, Tobias



 --------------070303030209030104070701-- From ynir@checkpoint.com Wed Aug 14 09:55:53 2013 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 4313321E80C7; Wed, 14 Aug 2013 09:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKKd8NgDsekE; Wed, 14 Aug 2013 09:55:47 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1F09F21E808C; Wed, 14 Aug 2013 09:55:17 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7EGtC6W026816; Wed, 14 Aug 2013 19:55:12 +0300 X-CheckPoint: {520BB670-1E-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Wed, 14 Aug 2013 19:55:12 +0300 From: Yoav Nir To: Sean Turner Thread-Topic: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) Thread-Index: AQHOmQlsFXmWJxTQ/kGarKEYKdLs8pmUuc6A Date: Wed, 14 Aug 2013 16:55:11 +0000 Message-ID: <296E0D02-A1FB-4050-9DF6-06C60199AB32@checkpoint.com> References: <20130814161444.6218.82572.idtracker@ietfa.amsl.com> In-Reply-To: <20130814161444.6218.82572.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.33] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 110af5605b40a66fcd245c18ea2a4ad8d1ded19f57 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , The IESG , "" Subject: Re: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 14 Aug 2013 16:55:53 -0000 On Aug 14, 2013, at 7:14 PM, Sean Turner wrote: >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > It's interesting to note that this draft says there's a problem with > folks not checking the origins of the entire ancestor tree of names of > the framing resource - but then doesn't say that sounds like a good idea > do it. I can see the argument that might be made that this draft is just > documenting what's done now, but shouldn't we take the opportunity to do > more and recommend something along the lines of "The entire ancestor tree > of names of the framing resource SHOULD be checked to mitigate the risk > of attacks in multiple-nested scenarios" or something like that? The charter mandate was to just document. I think advise to web masters mig= ht be in scope, but advise for browser makers (for example, how to harmoniz= e the implementations) is not. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I'd ask about how RFC 6648 applies to this, but I bet this header was out > long before the drafts that lead to RFC 6648. 3-4 years before Peter's first draft. > s1 (penultimate paragraph): r/script/Javascript ? Any script. Flash can do scripting. > s4.1: Is Figure 1 missing or is that the registration template? ;) >=20 > s5: > r/all kinds of these attack vectors/these kind of attack vectors > r/, ...)/) >=20 > Appendix A: Is this a guarantee that x-frame-options/frame-options will > be supported henceforth until the end of time in those browsers?=20 > Basically, I'm not sure Appendix A is needed. >=20 >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From trevp@trevp.net Wed Aug 14 10:20:26 2013 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 257B421E80BA for ; Wed, 14 Aug 2013 10:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_BACKHAIR_43=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uIC1jeG2-tw for ; Wed, 14 Aug 2013 10:20:20 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 103D821F9A8C for ; Wed, 14 Aug 2013 10:20:18 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id e12so7655811wgh.21 for ; Wed, 14 Aug 2013 10:20:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KLOFMsbviYfDlEv9O2pkxFAxZtJIwfncrNkB2s4gg4I=; b=nMc+/GQz9Ts1TVpBdY5TFbNHHaFgECjkIPz9pqxNUuSnLz5Anu/qnM/BQ1jHe5XUDP nbT/WP0m58gQLEQ1Ndi75B3kwmR4w1F11N0/Q6oTinjIX0LhU+xMP89lPVaBgTj4aANz GiY4fidKq9IhD+GZd2SOtYodhaGAyaRRBg/olhx07o3zjTPtWJsmz61cjVGSbJSbCQnI XMTN8pLjjtLbSBbCoo0jyIEP8IL30W82upEWyOtaIPhxh1A3YtWBaegUUIXQZ/m05Myx h352JFsWspvPeO5/EMMwsrK2XZpEf5SPjpzKQE6GmZG+ygUlkokUKtGAQsBjShiUaGRS epww== X-Gm-Message-State: ALoCoQmy0nzbT6fZR4uMelIfxtX6HxZwZOArjr64/NP78DKIrJKkT1nQOO+LxsPcU0uZhWLT/MF4 MIME-Version: 1.0 X-Received: by 10.180.205.236 with SMTP id lj12mr6558461wic.22.1376500817975; Wed, 14 Aug 2013 10:20:17 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Wed, 14 Aug 2013 10:20:17 -0700 (PDT) X-Originating-IP: [166.137.184.39] In-Reply-To: <5209FF9D.1080208@mozilla.org> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <52089A35.9040103@mozilla.org> <52091598.7000306@mozilla.org> <5209FF9D.1080208@mozilla.org> Date: Wed, 14 Aug 2013 10:20:17 -0700 Message-ID: From: Trevor Perrin To: Gervase Markham Content-Type: text/plain; charset=ISO-8859-1 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 14 Aug 2013 17:20:26 -0000 On Tue, Aug 13, 2013 at 2:42 AM, Gervase Markham wrote: > On 13/08/13 07:40, Trevor Perrin wrote: >> Names are also smaller, and easier to configure, review, and debug >> than lists of hash values. > > Sure. No-one is denying that there are some advantages to using names; > the question is whether those advantages are worth it given the > significant downsides. The only real downside I've heard is that this would be a lot of work which people don't want to tackle now. Which is fine, but I hope we can revisit this later. > In terms of how to proceed, I suggest the wise thing is to define the > syntax so it is open to being extended with names or other identifiers > later, but get the standard done without that facility. Then, we don't > have to let the best be the enemy of the good. Per current spec, any new directives will be ignored by old browsers. Do we want the ability for new directives to be somehow marked "critical", so that an HPKP header is ignored if these new directive aren't understood? >>> It's well known and understood that not every user updates their browser >>> every cycle. Or, when and if pinning is integrated into an OS, they don't >>> always update their OS. So you will quickly have a situation, very easily >>> within a few releases, of the name 'Foo CA' ambiguously referring to >>> multiple different sets of SPKIs. >> >> Browsers would need to stop using name->key mappings that aren't >> current (say, more than 30 days old). > > And so HPKP no longer works for those sites in those browsers? That > doesn't sound great from a security standpoint to me. It also makes > using names clearly worse for the site than using hashes. HPKP pins based on stale name<->key mappings would not be applied. I think any instantiation of this concept would have to work that way. A browser that's been somehow cut-off from security updates for a long time will have other vulnerabilities (preloaded pins will be disabled, security holes will be unpatched, blacklists and revocation data will be absent, etc). > That's rather a big change in the idea to be throwing in as a bullet > point mid-way through a discussion. Forgive me, but it rather seems like > you are making this up as you go along rather than having thought it > through and presented a coherent proposal. Well, I am. The hard part of this is what communication / coordination / registry mechanisms can be set up for CAs to coordinate this with browsers. I don't have a good sense of that. >>> This is independent of mergers - CAs that are issuing new intermediates, >>> or deprecating old roots, etc. >> >> Yes, but either these get tracked by browsers, or they need to be >> tracked by every website using an affected CA pin. > > If the idea of using names is greater simplicity for sites, imposing a > requirement that they track the goings-on in the CA industry seems not > to meet that goal. There's some misunderstanding. My point is that changes like CAs issuing new intermediates or deprecating old roots MUST get incorporated into website pins somehow. Either every website using CA pins has to keep track of these changes and make these updates (current system). Or only the browsers have to do this (named pins). Most of the objections people have been raising come down to: "Pinning CA keys is hard, CA keys change over time and between root stores, how could browsers possibly keep track of this..." Any my counter is: Yes! It's hard! Which is why I'd much rather have a few browsers keep track of it then ask every website deployer to do so. >> I could imagine the former becoming widely used. Websites could >> easily see what other websites are doing, discuss and compare which >> CAs they consider good choices, and test and review their deployments. >> CAs would be incentivized to opt-in to this system by making it easy >> for browsers to pin them, and to provide good security so that >> websites would choose to include them into pins. > > Can't CA's help in the current system? Of course, and they'll have to. The question is whether they should be publishing this data for every pinned website to track, or every browser to track. > "Here's the set of 3 opaque > strings you should add to your HPKP header to pin to our consumer roots" > is not all that much more complex than "Here's a string that looks like > a domain name you should add to your HPKP header to pin to our consumer > roots". I disagree, configuring long lists of random-appearing strings that require frequent updating is much harder than configuring a few readable names that almost never change. But I suppose this is a debate that can be resumed in a year or two when we've got more experience. Trevor From ynir@checkpoint.com Wed Aug 14 10:31:19 2013 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 AC64D21E80C4 for ; Wed, 14 Aug 2013 10:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_43=1, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eexTYdWs09SQ for ; Wed, 14 Aug 2013 10:31:14 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D3FA521F9DAF for ; Wed, 14 Aug 2013 10:31:13 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7EHVBLU007844; Wed, 14 Aug 2013 20:31:11 +0300 X-CheckPoint: {520BBEDF-7-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Wed, 14 Aug 2013 20:31:10 +0300 From: Yoav Nir To: Trevor Perrin Thread-Topic: [websec] #58: Should we pin only SPKI, or also names Thread-Index: AQHOjHagv3/BmvZ4wU6WrbkIw+Bd/ZmAXZOAgAADk4CAAHu6gIAIRDGAgAJ+5gCAA6qMgIAB0yuAgACEa4CAAA6sAIAAYXWAgACClYCAADLvgIACEiGAgAADIYA= Date: Wed, 14 Aug 2013 17:31:10 +0000 Message-ID: <0E8707B2-60C2-407D-9BAE-1A0CEEAEBC7E@checkpoint.com> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <52089A35.9040103@mozilla.org> <52091598.7000306@mozilla.org> <5209FF9D.1080208@mozilla.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.33] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11e042ff1c7c9b0d9c93fd72aec50df796f37e11c5 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 14 Aug 2013 17:31:19 -0000 On Aug 14, 2013, at 8:20 PM, Trevor Perrin wrote: > On Tue, Aug 13, 2013 at 2:42 AM, Gervase Markham wrote= : >> On 13/08/13 07:40, Trevor Perrin wrote: >>> Names are also smaller, and easier to configure, review, and debug >>> than lists of hash values. >>=20 >> Sure. No-one is denying that there are some advantages to using names; >> the question is whether those advantages are worth it given the >> significant downsides. >=20 > The only real downside I've heard is that this would be a lot of work > which people don't want to tackle now. >=20 > Which is fine, but I hope we can revisit this later. Sure, we can. >> In terms of how to proceed, I suggest the wise thing is to define the >> syntax so it is open to being extended with names or other identifiers >> later, but get the standard done without that facility. Then, we don't >> have to let the best be the enemy of the good. >=20 > Per current spec, any new directives will be ignored by old browsers. >=20 > Do we want the ability for new directives to be somehow marked > "critical", so that an HPKP header is ignored if these new directive > aren't understood? Since pins have an OR relationship between them, a UA has to record all the= possible pins, or none. If we get "pin-sha1=3Dxxxxxxx ; pin-named=3Dhonest= -abes-used-cars-and-certificates.com" and you note only the one you underst= and (the first), you will block access to the site if the certificate turns= out to no longer fit the first pin, even if it does fit the second pin. So at least new pin encodings need to be critical. >=20 >>>> It's well known and understood that not every user updates their brows= er >>>> every cycle. Or, when and if pinning is integrated into an OS, they do= n't >>>> always update their OS. So you will quickly have a situation, very eas= ily >>>> within a few releases, of the name 'Foo CA' ambiguously referring to >>>> multiple different sets of SPKIs. >>>=20 >>> Browsers would need to stop using name->key mappings that aren't >>> current (say, more than 30 days old). >>=20 >> And so HPKP no longer works for those sites in those browsers? That >> doesn't sound great from a security standpoint to me. It also makes >> using names clearly worse for the site than using hashes. >=20 > HPKP pins based on stale name<->key mappings would not be applied. I > think any instantiation of this concept would have to work that way. >=20 > A browser that's been somehow cut-off from security updates for a long > time will have other vulnerabilities (preloaded pins will be disabled, > security holes will be unpatched, blacklists and revocation data will > be absent, etc). That's fine for a browser, but website administrators will also be required= to check whether the string that they entered still means what they though= it means. They will be required to check this periodically. >> That's rather a big change in the idea to be throwing in as a bullet >> point mid-way through a discussion. Forgive me, but it rather seems like >> you are making this up as you go along rather than having thought it >> through and presented a coherent proposal. >=20 > Well, I am. >=20 > The hard part of this is what communication / coordination / registry > mechanisms can be set up for CAs to coordinate this with browsers. I > don't have a good sense of that. I think the browser-CA communications is the easy part. It's the CA-EE comm= unications that is hard. >=20 >=20 >>>> This is independent of mergers - CAs that are issuing new intermediate= s, >>>> or deprecating old roots, etc. >>>=20 >>> Yes, but either these get tracked by browsers, or they need to be >>> tracked by every website using an affected CA pin. >>=20 >> If the idea of using names is greater simplicity for sites, imposing a >> requirement that they track the goings-on in the CA industry seems not >> to meet that goal. >=20 > There's some misunderstanding. >=20 > My point is that changes like CAs issuing new intermediates or > deprecating old roots MUST get incorporated into website pins somehow. >=20 > Either every website using CA pins has to keep track of these changes > and make these updates (current system). >=20 > Or only the browsers have to do this (named pins). >=20 > Most of the objections people have been raising come down to: "Pinning > CA keys is hard, CA keys change over time and between root stores, how > could browsers possibly keep track of this..." >=20 > Any my counter is: Yes! It's hard! Which is why I'd much rather > have a few browsers keep track of it then ask every website deployer > to do so. >=20 >=20 >>> I could imagine the former becoming widely used. Websites could >>> easily see what other websites are doing, discuss and compare which >>> CAs they consider good choices, and test and review their deployments. >>> CAs would be incentivized to opt-in to this system by making it easy >>> for browsers to pin them, and to provide good security so that >>> websites would choose to include them into pins. >>=20 >> Can't CA's help in the current system? >=20 > Of course, and they'll have to. >=20 > The question is whether they should be publishing this data for every > pinned website to track, or every browser to track. >=20 >=20 >> "Here's the set of 3 opaque >> strings you should add to your HPKP header to pin to our consumer roots" >> is not all that much more complex than "Here's a string that looks like >> a domain name you should add to your HPKP header to pin to our consumer >> roots". >=20 > I disagree, configuring long lists of random-appearing strings that > require frequent updating is much harder than configuring a few > readable names that almost never change. >=20 > But I suppose this is a debate that can be resumed in a year or two > when we've got more experience. +1= From Ted.Lemon@nominum.com Wed Aug 14 10:33:19 2013 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 8B9A821E80BA; Wed, 14 Aug 2013 10:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9egjnLKpaxR1; Wed, 14 Aug 2013 10:33:13 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 00B4C11E811F; Wed, 14 Aug 2013 10:33:12 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUgu/WJSVe8n+EpjasIJipyMOrojBpCdZ@postini.com; Wed, 14 Aug 2013 10:33:13 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 69B8F1B8288; Wed, 14 Aug 2013 10:33:12 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 637C819006C; Wed, 14 Aug 2013 10:33:12 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 14 Aug 2013 10:33:12 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1793.4\)) From: Ted Lemon In-Reply-To: <296E0D02-A1FB-4050-9DF6-06C60199AB32@checkpoint.com> Date: Wed, 14 Aug 2013 13:33:10 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <59CD902A-8992-452D-A9F1-C019016F6025@nominum.com> References: <20130814161444.6218.82572.idtracker@ietfa.amsl.com> <296E0D02-A1FB-4050-9DF6-06C60199AB32@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1793.4) X-Originating-IP: [192.168.1.10] Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, Sean Turner , websec@ietf.org, The IESG , websec-chairs@tools.ietf.org Subject: Re: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 14 Aug 2013 17:33:19 -0000 On Aug 14, 2013, at 12:55 PM, Yoav Nir wrote: > The charter mandate was to just document. I think advise to web = masters might be in scope, but advise for browser makers (for example, = how to harmonize the implementations) is not. The document seems to currently contain quite a bit of advice for = browser makers, and certainly for plugin makers. If the above = statement is really true, that advice seems like it's out of scope. If = the above statement is not true, then the advice ought to be complete. From tobias.gondrom@gondrom.org Wed Aug 14 10:41:34 2013 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 33FFD21E80C7 for ; Wed, 14 Aug 2013 10:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.361 X-Spam-Level: X-Spam-Status: No, score=-95.361 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hl5AmIktHOXN for ; Wed, 14 Aug 2013 10:41:29 -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 6186111E8180 for ; Wed, 14 Aug 2013 10:41:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=iDW0ddDidLy6tmWk8PEJkfI851P3g9O7VwXxQzZNDujh//GNRdMzaNMpFxQ98pbt7O3AyP5z5vQxaeKMd0rlQUjsg2XLywOuxm4xYBZ+1fUuysQP+5fSnfZRTomdRb50; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 17682 invoked from network); 14 Aug 2013 19:41:28 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.64?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 14 Aug 2013 19:41:28 +0200 Message-ID: <520BC148.4010505@gondrom.org> Date: Wed, 14 Aug 2013 18:41:28 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: ted.lemon@nominum.com References: <20130814161444.6218.82572.idtracker@ietfa.amsl.com> <296E0D02-A1FB-4050-9DF6-06C60199AB32@checkpoint.com> <59CD902A-8992-452D-A9F1-C019016F6025@nominum.com> In-Reply-To: <59CD902A-8992-452D-A9F1-C019016F6025@nominum.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------030201020408050803050204" Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, iesg@ietf.org, turners@ieca.com, websec-chairs@tools.ietf.org Subject: Re: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 14 Aug 2013 17:41:34 -0000 This is a multi-part message in MIME format. --------------030201020408050803050204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 14/08/13 18:33, Ted Lemon wrote: > On Aug 14, 2013, at 12:55 PM, Yoav Nir wrote: >> The charter mandate was to just document. I think advise to web masters might be in scope, but advise for browser makers (for example, how to harmonize the implementations) is not. > The document seems to currently contain quite a bit of advice for browser makers, and certainly for plugin makers. If the above statement is really true, that advice seems like it's out of scope. If the above statement is not true, then the advice ought to be complete. > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec Ted, it is a balancing act: the depth of advise is proportionate to the correlation of the different implementations. So e.g. where implementations are in sync, the advise is more detailed. We could add a section on the how to handle nested frames, but as we have two diverging major browser implementations in this point, that didn't feel very productive, especially as we have the hope that CSP1.1 will replace X-Frame-Options in the future. Best regards, Tobias --------------030201020408050803050204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 14/08/13 18:33, Ted Lemon wrote:
On Aug 14, 2013, at 12:55 PM, Yoav Nir <ynir@checkpoint.com> wrote:

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

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

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

Ted,

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

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

Best regards, Tobias



 --------------030201020408050803050204-- From ted.lemon@nominum.com Wed Aug 14 10:51:22 2013 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 B41B321E80D2; Wed, 14 Aug 2013 10:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMHkRRkaWd8V; Wed, 14 Aug 2013 10:51:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A5121F8CDD; Wed, 14 Aug 2013 10:51:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130814175121.16080.58938.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2013 10:51:21 -0700 Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, websec-chairs@tools.ietf.org Subject: [websec] Ted Lemon's No Objection on draft-ietf-websec-x-frame-options-09: (with COMMENT) 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, 14 Aug 2013 17:51:22 -0000 Ted Lemon has entered the following ballot position for draft-ietf-websec-x-frame-options-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The introduction of the concept of origins in 2.1 is a bit clumsy=E2=80=94t= he term is used under the SAMEORIGIN heading without being defined, and is later defined as a constraint specific only to ALLOW-FROM. Text about browser implementations for SAMEORIGIN and ALLOW-FROM is repeated here and in later sections. It would be better to simply refer to the later section. If I were to clean up this section, I would do something like the following: DENY A browser receiving content with this header MUST NOT display this content in any frame. SAMEORIGIN A browser receiving content with this header field MUST NOT display this content in any frame from a page of different origin than the content itself. If a browser or plugin can not reliably determine whether the origin of the content and the frame have the same origin, this MUST be treated as "DENY". Section 2.3.2.2 documents variations in the handling of this header field by different browsers. ALLOW-FROM (followed by a URI [RFC3986] of a trusted origin) A browser receiving content with this header MUST NOT display this content in a frame from any page with a top-level browsing context of different origin than the specified origin. While this can expose the page to risks by the trusted origin, in some cases it may be necessary to allow the framing by content from other domains. The meaning of the term "origin" is given in [RFC6454]. If the ALLOW-FROM value is used, it MUST be followed by a valid URI. Any data beyond the domain address (i.e. any data after the "/" separator) is to be ignored. And the algorithm to compare origins from [RFC6454] SHOULD be used to verify that a referring page is of the same origin as the content or that the referring page's origin is identical with the ALLOW-FROM URI. Though in conflict with [RFC6454], current implementations do not consider the port as a defining component of the origin. I also noticed that in another exchange about this document, someone said that this document is not intended to give advice to browser vendors. = If that's the case, what is the above SHOULD doing in the text? Is there uncertainty as to what implementations do? If so, it would be better to express that uncertainty, if indeed you are documenting browser behavior. Also, with respect to this text: Though in conflict with [RFC6454], current implementations do not consider the port as a defining component of the origin. Does this mean that http://www.foo.com and http://www.foo.com:8080 are considered equivalent, or that http://www.foo.com and http://www.foo.com:80 are _not_ considered equivalent? What about http://www.foo.com and https://www.foo.com? The following text is incomprehensible to me as a non-domain-expert: The criteria for the SAMEORIGIN option is not evaluated unanimously either: one implementation may evaluate the SAMEORIGIN option based on the origin of the framed page and the framing page, while another may evaluate based on the framed page and the top-level browsing- context. What is the distinction between "top-level browsing context" and "origin of the framing page?" A reference here would be helpful. Thanks for documenting this. From Ted.Lemon@nominum.com Wed Aug 14 10:52:56 2013 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 99B4421E80DD; Wed, 14 Aug 2013 10:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNN8ZSMdaSbn; Wed, 14 Aug 2013 10:52:50 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 130B321E80C7; Wed, 14 Aug 2013 10:52:49 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUgvD8Gut1Mcfk2DE9X66+5DeFUFUu7jQ@postini.com; Wed, 14 Aug 2013 10:52:49 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9F8071B82A7; Wed, 14 Aug 2013 10:52:48 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 83A3519006C; Wed, 14 Aug 2013 10:52:48 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 14 Aug 2013 10:52:48 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_20733533-2D90-4037-969B-7D939CFD26B8" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1793.4\)) From: Ted Lemon In-Reply-To: <520BC148.4010505@gondrom.org> Date: Wed, 14 Aug 2013 13:52:47 -0400 Message-ID: References: <20130814161444.6218.82572.idtracker@ietfa.amsl.com> <296E0D02-A1FB-4050-9DF6-06C60199AB32@checkpoint.com> <59CD902A-8992-452D-A9F1-C019016F6025@nominum.com> <520BC148.4010505@gondrom.org> To: Tobias Gondrom X-Mailer: Apple Mail (2.1793.4) X-Originating-IP: [192.168.1.10] Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, The IESG , Sean Turner , websec-chairs@tools.ietf.org Subject: Re: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 14 Aug 2013 17:52:56 -0000 --Apple-Mail=_20733533-2D90-4037-969B-7D939CFD26B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" On Aug 14, 2013, at 1:41 PM, Tobias Gondrom = wrote: > it is a balancing act: the depth of advise is proportionate to the = correlation of the different implementations.=20 > So e.g. where implementations are in sync, the advise is more = detailed.=20 Right, I get the sense that the goal really is to document, not to = advise, at least with respect to browser vendors. I just posted some = comments that speak to this question=97I think you are doing the right = thing, but you just should be clear that you are documenting existing = behavior rather than specifying behavior. That probably means that = there are some bits of text that look normative right now that ought to = be reworded. --Apple-Mail=_20733533-2D90-4037-969B-7D939CFD26B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252" On Aug = 14, 2013, at 1:41 PM, Tobias Gondrom <tobias.gondrom@gondrom.org&= gt; wrote:
it is a balancing act: the = depth of advise is proportionate to the correlation of the different = implementations. 
So e.g. where implementations are in sync, the advise is = more detailed. 

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

= --Apple-Mail=_20733533-2D90-4037-969B-7D939CFD26B8-- From tobias.gondrom@gondrom.org Wed Aug 14 10:56:47 2013 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 3FE7E21E80C7 for ; Wed, 14 Aug 2013 10:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LF+SBPKC5Ze for ; Wed, 14 Aug 2013 10:56:47 -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 49CAD21E80DB for ; Wed, 14 Aug 2013 10:56:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=CGQmPcEldj5jTZ31lUJIRKW4U95fnDYRCwezH5m8iprYD58LCReGNGGmuqn6733x57AoTxd71fJ8Q9hSBCLZIrZttXIAh9BnL5hCUA45nkaYF9cfl1KFpURYtsd/CcNN; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 17828 invoked from network); 14 Aug 2013 19:56:38 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.64?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 14 Aug 2013 19:56:38 +0200 Message-ID: <520BC4D5.40401@gondrom.org> Date: Wed, 14 Aug 2013 18:56:37 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: ynir@checkpoint.com, turners@ieca.com References: <20130814161444.6218.82572.idtracker@ietfa.amsl.com> <296E0D02-A1FB-4050-9DF6-06C60199AB32@checkpoint.com> In-Reply-To: <296E0D02-A1FB-4050-9DF6-06C60199AB32@checkpoint.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, iesg@ietf.org, websec-chairs@tools.ietf.org Subject: Re: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 14 Aug 2013 17:56:47 -0000 On 14/08/13 17:55, Yoav Nir wrote: > On Aug 14, 2013, at 7:14 PM, Sean Turner wrote: > >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> It's interesting to note that this draft says there's a problem with >> folks not checking the origins of the entire ancestor tree of names of >> the framing resource - but then doesn't say that sounds like a good idea >> do it. I can see the argument that might be made that this draft is just >> documenting what's done now, but shouldn't we take the opportunity to do >> more and recommend something along the lines of "The entire ancestor tree >> of names of the framing resource SHOULD be checked to mitigate the risk >> of attacks in multiple-nested scenarios" or something like that? > The charter mandate was to just document. I think advise to web masters might be in scope, but advise for browser makers (for example, how to harmonize the implementations) is not. See also my reply to Ted's email. >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I'd ask about how RFC 6648 applies to this, but I bet this header was out >> long before the drafts that lead to RFC 6648. > 3-4 years before Peter's first draft. Yes the header was there long before 6648. But we refer to 6648 in the draft. > >> s1 (penultimate paragraph): r/script/Javascript ? > Any script. Flash can do scripting. Agree with Yoav. Though the main use case is Javascript. I would suggest to keep "script" here. > >> s4.1: Is Figure 1 missing or is that the registration template? ;) Yes, Figure 1 is the template. I did it in form of a template to maintain static formating and xml2rfc generates the "Figure 1" at the bottom automatically. I guess this can be mitigated by the RFC-Editor later. >> >> s5: >> r/all kinds of these attack vectors/these kind of attack vectors >> r/, ...)/) No. The correction would change the meaning of the sentence. (to be clear it does help against many of the attack vectors, just not all...) >> >> Appendix A: Is this a guarantee that x-frame-options/frame-options will >> be supported henceforth until the end of time in those browsers? >> Basically, I'm not sure Appendix A is needed. Obviously it is not a guarantee that x-frame-options shall be supported henceforth until the end of time. In fact the opposite is true: we hope that one day it will be replaced by CSP1.1. However, people in the WG felt it would be good to document the current use/implementations of X-Frame-Options in this draft (though I don't remember whether there were any strong opinions on that bit). >> >> >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec From tobias.gondrom@gondrom.org Wed Aug 14 14:08:22 2013 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 599CD11E81B4 for ; Wed, 14 Aug 2013 14:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGsQc14YafkC for ; Wed, 14 Aug 2013 14:08:07 -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 6BB1011E81AD for ; Wed, 14 Aug 2013 14:07:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=mUq0KTmBeYukVK/n1U83D5WjenfcFpz/S5+MwVkifm9A0pV1AUlrTDdssThwcUi2pZh2GM6ymePqUhROrpGXTZww/NEt+GotPDAgu+AwxNPSPfGcIOEOh3SwoY9xPe6A; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 20136 invoked from network); 14 Aug 2013 23:07:55 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.64?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 14 Aug 2013 23:07:55 +0200 Message-ID: <520BF1AB.5000103@gondrom.org> Date: Wed, 14 Aug 2013 22:07:55 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: ted.lemon@nominum.com References: <20130814175121.16080.58938.idtracker@ietfa.amsl.com> In-Reply-To: <20130814175121.16080.58938.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, iesg@ietf.org, websec-chairs@tools.ietf.org Subject: Re: [websec] Ted Lemon's No Objection on draft-ietf-websec-x-frame-options-09: (with COMMENT) 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, 14 Aug 2013 21:08:22 -0000 Hi Ted, thanks for the review and your comments. Answers inline. I included your feedback comments in version-10 as outlined below (which I hold back for one day as the changes are not material and I like to combine them with other potentially upcoming feedback) Thanks for the review and all the best, Tobias Best regards, Tobias On 14/08/13 18:51, Ted Lemon wrote: > Ted Lemon has entered the following ballot position for > draft-ietf-websec-x-frame-options-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The introduction of the concept of origins in 2.1 is a bit clumsy—the > term is used under the SAMEORIGIN heading without being defined, and is > later defined as a constraint specific only to ALLOW-FROM. Text about > browser implementations for SAMEORIGIN and ALLOW-FROM is repeated here > and in later sections. It would be better to simply refer to the later > section. If I were to clean up this section, I would do something like > the following: > > DENY > A browser receiving content with this header MUST NOT display > this content in any frame. > > SAMEORIGIN > A browser receiving content with this header field MUST NOT > display this content in any frame from a page of different > origin than the content itself. > If a browser or plugin can not reliably determine whether the > origin of the content and the frame have the same origin, this > MUST be treated as "DENY". Section 2.3.2.2 documents > variations in the handling of this header field by different > browsers. Hm. I see your point. My solution would be close to your suggestion: (But not to remove the text before about the variations in implementations) and add the following text at the end: "See also section 2.3.2.2 documents variations in the handling of this header field by different browsers." > > ALLOW-FROM (followed by a URI [RFC3986] of a trusted origin) > A browser receiving content with this header MUST NOT display > this content in a frame from any page with a top-level browsing > context of different origin than the specified origin. While > this can expose the page to risks by the trusted origin, in > some cases it may be necessary to allow the framing by content > from other domains. > > The meaning of the term "origin" is given in [RFC6454]. Ok. I added this line as you suggest. > If the ALLOW-FROM value is used, it MUST be followed by a valid URI. > Any data beyond the domain address (i.e. any data after the "/" > separator) is to be ignored. And the algorithm to compare origins > from [RFC6454] SHOULD be used to verify that a referring page is of > the same origin as the content or that the referring page's origin is > identical with the ALLOW-FROM URI. Though in conflict with > [RFC6454], current implementations do not consider the port as a > defining component of the origin. > > I also noticed that in another exchange about this document, someone said > that this document is not intended to give advice to browser vendors. > If that's the case, what is the above SHOULD doing in the text? Is > there uncertainty as to what implementations do? If so, it would be > better to express that uncertainty, if indeed you are documenting browser > behavior. > > Also, with respect to this text: > > Though in conflict with > [RFC6454], current implementations do not consider the port as a > defining component of the origin. > > Does this mean that http://www.foo.com and http://www.foo.com:8080 are > considered equivalent, or that http://www.foo.com and > http://www.foo.com:80 are _not_ considered equivalent? What about > http://www.foo.com and https://www.foo.com? As outline in RFC6454, origin identity is defined by the triplet protocol, address and port. If all three are identical, the origin is the same, otherwise not. As written in the draft, current implementations do not consider the port as a defining component of the origin, this means that only protocol and address are defining criteria, i.e. http://www.foo.com:8080 and http://www.foo.com are read as from the same origin. (and http://www.foo.com and https://www.foo.com are _not_ same origin) I had the hope with referring to RFC6454 this should be unambiguous and clear enough. I had the hesitation to write redundant text, but maybe I got too short. Do you think we need to spell it out more explicitly in the draft so people understand? [will keep the text as is until I hear an argument that this is indeed not clear enough yet.] > > The following text is incomprehensible to me as a non-domain-expert: > > The criteria for the SAMEORIGIN option is not evaluated unanimously > either: one implementation may evaluate the SAMEORIGIN option based > on the origin of the framed page and the framing page, while another > may evaluate based on the framed page and the top-level browsing- > context. > > What is the distinction between "top-level browsing context" and "origin > of the framing page?" A reference here would be helpful. Apologies. In this case I have hesitations to add an explanation about the nesting of frames in html. In general the concept of nested frames (and top-level vs. framing page) is reasonably understood. [will keep the text as is until I hear an argument that this really needs an explanation in this draft.] > > Thanks for documenting this. > > From Ted.Lemon@nominum.com Wed Aug 14 14:49:36 2013 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 E8DFC21F90CC; Wed, 14 Aug 2013 14:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9Z3fxBakGxc; Wed, 14 Aug 2013 14:49:30 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6FC21F8C4C; Wed, 14 Aug 2013 14:49:30 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUgv7aZka8cx1EHc+AcZjTtYSKrbwHHdg@postini.com; Wed, 14 Aug 2013 14:49:30 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 73D531B82A8; Wed, 14 Aug 2013 14:49:29 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 57E8919006C; Wed, 14 Aug 2013 14:49:29 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [192.168.1.2] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 14 Aug 2013 14:49:29 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1793.4\)) From: Ted Lemon In-Reply-To: <520BF1AB.5000103@gondrom.org> Date: Wed, 14 Aug 2013 17:49:25 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <0B70B4E8-0375-414F-B529-52D3EE0E275B@nominum.com> References: <20130814175121.16080.58938.idtracker@ietfa.amsl.com> <520BF1AB.5000103@gondrom.org> To: Tobias Gondrom X-Mailer: Apple Mail (2.1793.4) X-Originating-IP: [192.168.1.10] Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, The IESG , websec-chairs@tools.ietf.org Subject: Re: [websec] Ted Lemon's No Objection on draft-ietf-websec-x-frame-options-09: (with COMMENT) 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, 14 Aug 2013 21:49:37 -0000 On Aug 14, 2013, at 5:07 PM, Tobias Gondrom = wrote: > I had the hope with referring to RFC6454 this should be unambiguous = and > clear enough. I had the hesitation to write redundant text, but maybe = I > got too short. Do you think we need to spell it out more explicitly in > the draft so people understand? How about: Existing implementations differ with [RFC6454] in that origins with the same protocol but different port values are considered equivalent. >> What is the distinction between "top-level browsing context" and = "origin >> of the framing page?" A reference here would be helpful. > Apologies. In this case I have hesitations to add an explanation about > the nesting of frames in html. In general the concept of nested frames > (and top-level vs. framing page) is reasonably understood. > [will keep the text as is until I hear an argument that this really > needs an explanation in this draft.] The additional text that you added in your reply helps a little=97it = appears that "top-level browsing context" means "the HTML that is loaded = first and that contains whatever nesting might occur" and perhaps that = "origin of the framing page" refers somehow to the idea of nested = frames. But even with the help you've given me in your reply, I am not = sure that I have this right, and indeed I am scratching my head trying = to figure out what the difference is between these two contexts. As a person who writes HTML fairly regularly, I think I am your intended = target audience. If so, you really do need to explain what these terms = mean, or provide a reference to a document that explains them. From barryleiba@gmail.com Wed Aug 14 15:15:37 2013 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 1E1BF21F9C6F; Wed, 14 Aug 2013 15:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.906 X-Spam-Level: X-Spam-Status: No, score=-101.906 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd587vNUWiaw; Wed, 14 Aug 2013 15:15:36 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 94D7E21F9BAB; Wed, 14 Aug 2013 15:15:36 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id cl20so1361826qab.16 for ; Wed, 14 Aug 2013 15:15:36 -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:message-id:subject :from:to:cc:content-type; bh=voi4OCFHSoxE3oW8fdNJPVx224rC/41a3gEaebaprNE=; b=KyFL9ngx7kqwWIo3t0npssiK47ddedv24gzdSFfA76irJUNk8NpyrquzzMJPJgzWKH ktcLJbcGAYzS3K+hTTYAfEIBldb+IxF5fJKnEX6SrgbTx30poThC1OQ2gQvDJXkWjXb5 utAom+XNgpXEmuK7DcxPniB1McUCRGhCA0xzz38OGl4Ox7G11Ns8p1RKudh4/99OQLYA 12A1CuBZiO5OHbY9SQ5LexgL6Gldh/LNlP9ffICIPZgFlVKo16SCGNlC3WDPBn/Ao2E3 I2SmvAKgCYGPQU7vsk9ZWjHCHGmjQBTxuy+AHK6gs87bfDaeRAXVoucNEe8DydpTgx2l WqRg== MIME-Version: 1.0 X-Received: by 10.224.97.66 with SMTP id k2mr4949777qan.109.1376518535991; Wed, 14 Aug 2013 15:15:35 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.59.211 with HTTP; Wed, 14 Aug 2013 15:15:35 -0700 (PDT) In-Reply-To: <20130814221250.16821.99472.idtracker@ietfa.amsl.com> References: <20130814221250.16821.99472.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2013 18:15:35 -0400 X-Google-Sender-Auth: y6d8KYpwJhcLsZSKHkCtXimIyVI Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , websec@ietf.org, The IESG , "websec-chairs@tools.ietf.org" Subject: Re: [websec] Pete Resnick's No Objection on draft-ietf-websec-x-frame-options-09: (with COMMENT) 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, 14 Aug 2013 22:15:37 -0000 > Why is this document not on the standards track? Because it's not anything we want to tell people to start implementing now. We want them to move toward the work we transferred over to W3C's WebAppSec group instead. b From stephen.farrell@cs.tcd.ie Wed Aug 14 15:48:03 2013 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 9DF9111E81BE; Wed, 14 Aug 2013 15:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rn146Rk219zA; Wed, 14 Aug 2013 15:48:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FC411E814D; Wed, 14 Aug 2013 15:48:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130814224803.25993.58131.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2013 15:48:03 -0700 Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, websec-chairs@tools.ietf.org Subject: [websec] Stephen Farrell's Yes on draft-ietf-websec-x-frame-options-09: (with COMMENT) 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, 14 Aug 2013 22:48:03 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-websec-x-frame-options-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (Personal opinion only, no change requested unless it resonates with folks.) I would prefer that this not say that NoScript impairs broswer utility. I find it fine. Other than that, this is a fine draft, thanks. From gerv@mozilla.org Wed Aug 14 16:44:55 2013 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 55D0621F8F4A for ; Wed, 14 Aug 2013 16:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDHqWno6j1Fw for ; Wed, 14 Aug 2013 16:44:49 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9346121F8F2E for ; Wed, 14 Aug 2013 16:44:49 -0700 (PDT) Received: from [192.168.1.138] (host86-146-213-39.range86-146.btcentralplus.com [86.146.213.39]) (Authenticated sender: gerv@mozilla.org) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 60F62F24D8; Wed, 14 Aug 2013 16:44:48 -0700 (PDT) Message-ID: <520C166E.7000202@mozilla.org> Date: Thu, 15 Aug 2013 00:44:46 +0100 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Trevor Perrin References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <52089A35.9040103@mozilla.org> <52091598.7000306@mozilla.org> <5209FF9D.1080208@mozilla.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 14 Aug 2013 23:44:55 -0000 On 14/08/13 18:20, Trevor Perrin wrote: > My point is that changes like CAs issuing new intermediates or > deprecating old roots MUST get incorporated into website pins somehow. Perhaps this is the point of disagreement. I would expect CAs to offer appropriate pinning advice with certificates, probably in the form of "paste this into your HPKP header". Once a cert is in use and pinned, no further changes to those pins need to be made. No matter what happens to the CA's business, as long as the root and intermediate you are using are still valid (and, absent a CA breach, they will be - no CA sells certs which use roots and intermediates which expire before the cert finishes its lifetime), you don't have to worry. When you get a new cert (renewal), you'll get updated pinning advice. If you have pinned a backup provider, you will no doubt have sought similar pinning advice from them. There is more of a risk that this advice will need to change at a different time from you changing your cert, but that's OK, because you can change this stuff as much as you like and all you have to do is wait for caches to empty (30 days?). Gerv From rlb@ipv.sx Wed Aug 14 18:41:21 2013 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 B481C11E80E0; Wed, 14 Aug 2013 18:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQ7Rw86F0GRz; Wed, 14 Aug 2013 18:41:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 375E321F9798; Wed, 14 Aug 2013 18:41:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Richard Barnes" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130815014121.17800.33179.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2013 18:41:21 -0700 Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, websec-chairs@tools.ietf.org Subject: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 15 Aug 2013 01:41:21 -0000 Richard Barnes has entered the following ballot position for draft-ietf-websec-x-frame-options-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (D1) The privacy considerations make no sense to me. To whom is data being leaked? To the browser? To random people who send a request to a URI? Do you mean that X-Frame-Options leaks information about who the site authorizes? That's true, but also true of things like CORS. If this is the concern, you should recommend a mitigation that's basically the same as what CORS does, namely varying the value of X-Frame-Options based on the Referer or Origin header. (D2) It seems like this is a value that browsers might cache, to avoid unnecessary requests if the same page is framed in the future. If this is something browsers do today, please say so. = (D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI? In other words, what does it mean to send "X-Frame-Options: ALLOW-FROM https://example.com/this/is/a/path?query#fragment"? = (D3) In the ALLOW-FROM: what does "top level context" mean? Do you really mean the top level here, as opposed to the next one up? For example, suppose A loads B in an iframe, and B loads C, and then C sends an X-Frame-Options header with ALLOW-FROM. Is the ALLOW-FROM origin compared to B or A? In either case, you should also note the attacks that remain. For example, if the answer is B, then B needs to use X-Frame-Options as well, or else, A can maliciously frame A within B. Or if the answer is A, then C is trusting A not to load any malicious intermediate frames B. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (C1) In the Introduction, the phrase "secure web page" would seem to imply that this mechanism only applies to pages delivered over HTTPS, which I'm pretty sure isn't true. Suggest just deleting "secure". (C2) In Section 2.1, the sentence starting "And the algorithm" seems to imply that ALLOW-FROM allows SAMEORIGIN requests as well, which I think you actually mean something like: """ And the algorithm to compare origins from [RFC6454] SHOULD be used to verify that a referring page is of the same origin as the content (in the case of SAMEORIGIN) or that the referring page's origin is identical with the ALLOW-FROM URI (in the case of ALLOW-FROM). = """ From joelja@bogus.com Wed Aug 14 20:41:56 2013 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 2E08121E8118; Wed, 14 Aug 2013 20:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-8ok+5PfL2k; Wed, 14 Aug 2013 20:41:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2ACA21E8108; Wed, 14 Aug 2013 20:41:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Joel Jaeggli" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130815034155.27991.62074.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2013 20:41:55 -0700 Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, websec-chairs@tools.ietf.org Subject: [websec] Joel Jaeggli's No Objection on draft-ietf-websec-x-frame-options-09: (with COMMENT) 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, 15 Aug 2013 03:41:56 -0000 Joel Jaeggli has entered the following ballot position for draft-ietf-websec-x-frame-options-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- support richards discussion, the security/privacy considerations could use some wordsmithing. From trevp@trevp.net Thu Aug 15 01:20:29 2013 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 6497D11E80C5 for ; Thu, 15 Aug 2013 01:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVrX2I7x8Wzv for ; Thu, 15 Aug 2013 01:20:23 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id DEA6321E811A for ; Thu, 15 Aug 2013 01:20:19 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hi8so261085wib.3 for ; Thu, 15 Aug 2013 01:20:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nS+ovhtXEJ5JZsR4TG0sH/PtxXMfwIXLkqTvXlQL9m8=; b=conNe/1xFl/TBPisXhSN9FXWaSwhd/ubH4402JGYEgqXMT8Ox83cW4kJB1n19Jlykl ez4tJx5hIKEcpcMBuCuTe6idEwHePoQRxvDbhA0PcKVeUM1l8eRFwcLWMDMg9Gv4Wji+ XMJywRgoIa8qP1UH850vS27M8v4YbzAnhPDCiBdCj46uNS8stK5LyZ8lg0miPkZGxhjP jVu2dBkoBc4v8+VNug/2HBMvlDD9EZGRmB3SP6/wVd/TGtx995klNhbaGAl6fJUeHOD7 lFmyY9/y3ikDVfWNjQ67+vk3OMWMfoYMOI6SupKIJ8roderUSHWI0BW6m5PR1y+YWz8T 1edQ== X-Gm-Message-State: ALoCoQkxyyGkapzEVc/DFOk9QIbUvY2HWDmAESrXTjxVyU0FoWPeYIUFxW9/ZAU0MGGqLYqj+TCb MIME-Version: 1.0 X-Received: by 10.180.205.236 with SMTP id lj12mr1120430wic.22.1376554818489; Thu, 15 Aug 2013 01:20:18 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Thu, 15 Aug 2013 01:20:18 -0700 (PDT) X-Originating-IP: [166.137.187.36] In-Reply-To: <520C166E.7000202@mozilla.org> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <52089A35.9040103@mozilla.org> <52091598.7000306@mozilla.org> <5209FF9D.1080208@mozilla.org> <520C166E.7000202@mozilla.org> Date: Thu, 15 Aug 2013 01:20:18 -0700 Message-ID: From: Trevor Perrin To: Gervase Markham Content-Type: text/plain; charset=ISO-8859-1 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 15 Aug 2013 08:20:29 -0000 On Wed, Aug 14, 2013 at 4:44 PM, Gervase Markham wrote: > On 14/08/13 18:20, Trevor Perrin wrote: >> My point is that changes like CAs issuing new intermediates or >> deprecating old roots MUST get incorporated into website pins somehow. > > Perhaps this is the point of disagreement. > > I would expect CAs to offer appropriate pinning advice with > certificates, probably in the form of "paste this into your HPKP > header". Once a cert is in use and pinned, no further changes to those > pins need to be made. So you're expecting sites to edit their HPKP header on every cert change? In that case I'd expect them to pin their end-entity key (see reasons below). I believe they'd have to edit the HPKP header twice: * Add their next end-entity key to the HPKP header * Wait for time T (where T is sufficient for all older pins to expire) * Switch to certificates with the new key * Once the switch is complete, delete the old key from the HPKP header Sound right? > No matter what happens to the CA's business, as > long as the root and intermediate you are using are still valid (and, > absent a CA breach, they will be - no CA sells certs which use roots and > intermediates which expire before the cert finishes its lifetime), you > don't have to worry. When you get a new cert (renewal), you'll get > updated pinning advice. In a strict sense I don't think this is true. You're assuming every end-entity cert "uses" a single root, which is constant for the lifetime of the cert absent a CA breach. But HPKP pins are checked against the browser-constructed cert path, which might contain intermediates and roots different from what the website sent, or thinks its "using". Example: You pin what you think is the root cert of your current certificate. 3 months later the intermediate is upgraded to a root in the browser's trust store, or becomes cross-certified by a different root. Your pin fails, as the browser no longer constructs paths that use the pinned root. See Ryan's explanation of AIA chasing for more on this [1]. While pinning the end-entity's immediate-parent intermediate doesn't have this problem, I don't see that it has any advantage over pinning the end-entity key directly. > If you have pinned a backup provider, you will no doubt have sought > similar pinning advice from them. There is more of a risk that this > advice will need to change at a different time from you changing your > cert, but that's OK, because you can change this stuff as much as you > like and all you have to do is wait for caches to empty (30 days?). Well, you *can* change your HPKP header as much as you like, but do you want to? If you pin several CAs, and find yourself having to edit the HPKP header multiple times a year, isn't that kind of a hassle? My point was not that it's impossible for websites to track CA key lists, just that it would be more user-friendly if they didn't have to. Trevor [1] http://www.ietf.org/mail-archive/web/websec/current/msg01425.html From gerv@mozilla.org Thu Aug 15 01:30:53 2013 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 BD30E11E80EA for ; Thu, 15 Aug 2013 01:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Goyzc8LEd4XK for ; Thu, 15 Aug 2013 01:30:47 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id BAC0611E8127 for ; Thu, 15 Aug 2013 01:30:47 -0700 (PDT) Received: from [192.168.0.101] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 77C73F22FA; Thu, 15 Aug 2013 01:30:45 -0700 (PDT) Message-ID: <520C91B3.20402@mozilla.org> Date: Thu, 15 Aug 2013 09:30:43 +0100 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Trevor Perrin References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <52089A35.9040103@mozilla.org> <52091598.7000306@mozilla.org> <5209FF9D.1080208@mozilla.org> <520C166E.7000202@mozilla.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 15 Aug 2013 08:30:53 -0000 On 15/08/13 09:20, Trevor Perrin wrote: > So you're expecting sites to edit their HPKP header on every cert > change? No; it's quite possible that the advice on renew would be "keep the same pins". And I'd expect the CA to talk about the trade-offs with the customer before offering their best advice for the customer's situation. > * Add their next end-entity key to the HPKP header > * Wait for time T (where T is sufficient for all older pins to expire) > * Switch to certificates with the new key > * Once the switch is complete, delete the old key from the HPKP header > > Sound right? Pinning to an end-entity key is indeed more work. I suspect that for most sites, the best trade-off will be pinning to two or three roots, one from each of two or three different CAs, where the CA has told them "yes, we issue certs from this root for sites like you, and will continue to do so for the forseeable future". >> No matter what happens to the CA's business, as >> long as the root and intermediate you are using are still valid (and, >> absent a CA breach, they will be - no CA sells certs which use roots and >> intermediates which expire before the cert finishes its lifetime), you >> don't have to worry. When you get a new cert (renewal), you'll get >> updated pinning advice. > > In a strict sense I don't think this is true. You're assuming every > end-entity cert "uses" a single root, which is constant for the > lifetime of the cert absent a CA breach. > > But HPKP pins are checked against the browser-constructed cert path, > which might contain intermediates and roots different from what the > website sent, or thinks its "using". That is true; however, a CA should be aware of the possible different constructible paths, and provide pinning advice which takes them into account. > Example: You pin what you think is the root cert of your current > certificate. 3 months later the intermediate is upgraded to a root in > the browser's trust store, or becomes cross-certified by a different > root. Your pin fails, as the browser no longer constructs paths that > use the pinned root. In this scenario, you seem to have failed to consult your CA for advice on how best to pin to their chain :-) > My point was not that it's impossible for websites to track CA key > lists, just that it would be more user-friendly if they didn't have > to. In the sense you are discussing, I agree an alias is less precise, and therefore more user-friendly. As I said previously, aliases are not _all_ bad. Gerv From trevp@trevp.net Thu Aug 15 02:09:20 2013 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 0359D11E8123 for ; Thu, 15 Aug 2013 02:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.852 X-Spam-Level: X-Spam-Status: No, score=-2.852 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tM57tdnxqeb for ; Thu, 15 Aug 2013 02:09:14 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0C35B11E8127 for ; Thu, 15 Aug 2013 02:09:07 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id en1so2885908wid.12 for ; Thu, 15 Aug 2013 02:09:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R4cZFkFuSDk2gVyAAeVAN/bAjGM+es6Jrr5AMzwQviw=; b=nofBGhk8I7debjgg6JpFA4OBMgoaKvqvjNqeW4GaRVmcu71OuON0XegGMRuw2SzZAL UQC2wD0x/aEfluM3dFnEhuIGPIGqWvavhZ1Cu5R8YASdrkUXVJYiCGbuoLK1jSVe0ANV yuxxo8gXST+XZk2zgUTV1sYBPIbPzz1R56tcdjIFs4cxnaJNwFc763p4bxlWVOJPMRii 7JwOoV2QQWG6nZG1wmSMnX1o4COJGUNrRI3rg9QfaUmOSSprsxRUjCYwDByKwpAagFfb oLMjLnLD+iKvcKjbDOgkBV29bDi/wyefa56spva32FN/gYJ2hfysF9LReoe3OdbmmYgL 8c1w== X-Gm-Message-State: ALoCoQmKdmsWlXkccTHBpsF80SjcIK6+h2FzfWUztFogF7Y2Rs4b8NSTjb8mIhhoG/QzNCYtl0e/ MIME-Version: 1.0 X-Received: by 10.180.97.226 with SMTP id ed2mr1236360wib.17.1376557740140; Thu, 15 Aug 2013 02:09:00 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Thu, 15 Aug 2013 02:08:59 -0700 (PDT) X-Originating-IP: [166.137.187.36] In-Reply-To: <520C91B3.20402@mozilla.org> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <52089A35.9040103@mozilla.org> <52091598.7000306@mozilla.org> <5209FF9D.1080208@mozilla.org> <520C166E.7000202@mozilla.org> <520C91B3.20402@mozilla.org> Date: Thu, 15 Aug 2013 02:08:59 -0700 Message-ID: From: Trevor Perrin To: Gervase Markham Content-Type: text/plain; charset=ISO-8859-1 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 15 Aug 2013 09:09:20 -0000 On Thu, Aug 15, 2013 at 1:30 AM, Gervase Markham wrote: > On 15/08/13 09:20, Trevor Perrin wrote: >> So you're expecting sites to edit their HPKP header on every cert >> change? > > No; it's quite possible that the advice on renew would be "keep the same > pins". OK. So you're expecting sites to request a new cert at least T days prior to their existing cert expiring (where T is the length of time needed for extant pins to expire). The CA will inform them whether any new keys need to be added or removed to the HPKP header, based on knowledge of their previous header. If new keys need to be added, the site will then go through an update process like I described before: * Add the new keys to the HPKP header * Wait for time T (where T is sufficient for all older pins to expire) * Switch to new certificate * Once the switch is complete, delete any old keys from the HPKP header Is this right? > And I'd expect the CA to talk about the trade-offs with the customer > before offering their best advice for the customer's situation. > >> * Add their next end-entity key to the HPKP header >> * Wait for time T (where T is sufficient for all older pins to expire) >> * Switch to certificates with the new key >> * Once the switch is complete, delete the old key from the HPKP header >> >> Sound right? > > Pinning to an end-entity key is indeed more work. Pinning to an end-entity key requires an update process on every key change. Pinning to root keys requires an update process less frequently. But the process is of similar complexity. > I suspect that for > most sites, the best trade-off will be pinning to two or three roots, > one from each of two or three different CAs, where the CA has told them > "yes, we issue certs from this root for sites like you, and will > continue to do so for the forseeable future". I suspect most sites would prefer to pin more CAs, for safety's sake. But I could be wrong. It would be be nice if each CA is able to indicate a single key for the customer. But I'm not sure if that's feasible or excessively risky. >>> No matter what happens to the CA's business, as >>> long as the root and intermediate you are using are still valid (and, >>> absent a CA breach, they will be - no CA sells certs which use roots and >>> intermediates which expire before the cert finishes its lifetime), you >>> don't have to worry. When you get a new cert (renewal), you'll get >>> updated pinning advice. >> >> In a strict sense I don't think this is true. You're assuming every >> end-entity cert "uses" a single root, which is constant for the >> lifetime of the cert absent a CA breach. >> >> But HPKP pins are checked against the browser-constructed cert path, >> which might contain intermediates and roots different from what the >> website sent, or thinks its "using". > > That is true; however, a CA should be aware of the possible different > constructible paths, and provide pinning advice which takes them into > account. Sure. But how paths for a *single* cert are constructed can change over time, independent of new cert issuance, which you're not accounting for. >> Example: You pin what you think is the root cert of your current >> certificate. 3 months later the intermediate is upgraded to a root in >> the browser's trust store, or becomes cross-certified by a different >> root. Your pin fails, as the browser no longer constructs paths that >> use the pinned root. > > In this scenario, you seem to have failed to consult your CA for advice > on how best to pin to their chain :-) No, they gave you correct advice at the time of issuance. The root key pin was sufficient. But things changed (due to, say, merger or business relationship change between CAs). Trevor From presnick@qti.qualcomm.com Wed Aug 14 15:12:52 2013 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 D02DF11E814D; Wed, 14 Aug 2013 15:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vl9OuddO7SFm; Wed, 14 Aug 2013 15:12:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 910A211E80F7; Wed, 14 Aug 2013 15:12:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130814221250.16821.99472.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2013 15:12:50 -0700 X-Mailman-Approved-At: Thu, 15 Aug 2013 02:14:24 -0700 Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, websec-chairs@tools.ietf.org Subject: [websec] Pete Resnick's No Objection on draft-ietf-websec-x-frame-options-09: (with COMMENT) 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, 14 Aug 2013 22:12:53 -0000 Pete Resnick has entered the following ballot position for draft-ietf-websec-x-frame-options-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Why is this document not on the standards track? From presnick@qti.qualcomm.com Wed Aug 14 20:21:40 2013 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 5585C11E80F6; Wed, 14 Aug 2013 20:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.932 X-Spam-Level: X-Spam-Status: No, score=-105.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YI0K2tM3Aas8; Wed, 14 Aug 2013 20:21:35 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id D5AF211E81C4; Wed, 14 Aug 2013 20:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1376536895; x=1408072895; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=d8cB0ADwVOg3aohRw34F55cr0nW+W1Qx4Vd3uSNDRsg=; b=fGoAl/cT5IGlgGqqxCEn/ARJHLx0diENs5rjeHwGqAzS6PVemtu1C4+E UYOCtn/b5eY6CQA6vlkRphXz3HxkOBog8+/dp9TSYVBGLjv+cB/LI/9ZN Lm/xi8yesMQTzahsk9aNGQcgZ2fY0g/el2xHriFVkWfJCaOPz44EeTxa5 c=; X-IronPort-AV: E=Sophos;i="4.89,881,1367996400"; d="scan'208";a="68524337" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 14 Aug 2013 20:21:35 -0700 X-IronPort-AV: E=Sophos;i="4.89,881,1367996400"; d="scan'208";a="584576325" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Aug 2013 20:21:35 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.146.2; Wed, 14 Aug 2013 20:21:35 -0700 Message-ID: <520C493C.9080208@qti.qualcomm.com> Date: Wed, 14 Aug 2013 22:21:32 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <20130814221250.16821.99472.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] X-Mailman-Approved-At: Thu, 15 Aug 2013 02:14:24 -0700 Cc: "" , websec@ietf.org, The IESG , "websec-chairs@tools.ietf.org" Subject: Re: [websec] Pete Resnick's No Objection on draft-ietf-websec-x-frame-options-09: (with COMMENT) 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, 15 Aug 2013 03:21:40 -0000 On 8/14/13 5:15 PM, Barry Leiba wrote: >> Why is this document not on the standards track? >> > Because it's not anything we want to tell people to start implementing > now. We want them to move toward the work we transferred over to > W3C's WebAppSec group instead. > It's probably worth having a line to that effect somewhere in the document. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From ynir@checkpoint.com Thu Aug 15 08:20:43 2013 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 ED0D221E8163 for ; Thu, 15 Aug 2013 08:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.537 X-Spam-Level: X-Spam-Status: No, score=-10.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6BrAuyFQ-1Z for ; Thu, 15 Aug 2013 08:20:38 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2355421F9991 for ; Thu, 15 Aug 2013 08:19:57 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7FFJlAB007923; Thu, 15 Aug 2013 18:19:47 +0300 X-CheckPoint: {520CF193-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Thu, 15 Aug 2013 18:19:46 +0300 From: Yoav Nir To: Trevor Perrin Thread-Topic: [websec] #58: Should we pin only SPKI, or also names Thread-Index: AQHOjHagv3/BmvZ4wU6WrbkIw+Bd/ZmAXZOAgAADk4CAAHu6gIAIRDGAgAJ+5gCAA6qMgIAB0yuAgACEa4CAAA6sAIAAYXWAgACClYCAADLvgIACEiGAgABrbACAAJAKAIAAAumAgAAKsYCAAGecgA== Date: Thu, 15 Aug 2013 15:19:46 +0000 Message-ID: References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <52089A35.9040103@mozilla.org> <52091598.7000306@mozilla.org> <5209FF9D.1080208@mozilla.org> <520C166E.7000202@mozilla.org> <520C91B3.20402@mozilla.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.3] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11a6fbe14f2281d334c19b6dd697ebddf900d7df4c Content-Type: text/plain; charset="us-ascii" Content-ID: <334B679E0E9B024BA3E39D16FBEF0EB7@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 15 Aug 2013 15:20:44 -0000 On Aug 15, 2013, at 12:08 PM, Trevor Perrin wrote: > On Thu, Aug 15, 2013 at 1:30 AM, Gervase Markham wrote= : >> On 15/08/13 09:20, Trevor Perrin wrote: >>> So you're expecting sites to edit their HPKP header on every cert >>> change? >>=20 >> No; it's quite possible that the advice on renew would be "keep the same >> pins". >=20 > OK. So you're expecting sites to request a new cert at least T days > prior to their existing cert expiring (where T is the length of time > needed for extant pins to expire). That would require either the sites to buy more certs than they need (and h= ave overlapping certs) or the CAs to issue future certs (notBefore date T d= ays in the future) and commit to the pinning data being valid for (validity= _period + T). Not rocket science, but somewhat error prone. OTOH if the site administrator pins the EE public key, they don't need to i= nvolve the CA at all. They just need to generate the key pair (or the certi= ficate request) T days in advance, and add the new pin to the HPKP header/r= esource. If someone were to ask me what a good pinning policy would be, I would say = that they need three pins most of the time: 1. for the EE certificate 2. for the current root CA 3. for some other root CA (that you trust) If the EE certificate is compromised, you issue a new one from the current = root CA, and update the pin. If the CA gets compromised, you issue a new cert from the backup root CA an= d update the pin (also with a new backup) T days before expiry, you generate a certreq, and add the new public key as= a fourth pin until you change the certificate.=20 The pinning idea became cool because static pinning caught the Diginotar br= each. A policy like this would detect fake certificates (as long as Diginot= ar was not your primary or backup CA). If CAs publish pin data on their website and guarantee that they will put a= ny change on their website at least x days before the change takes place (9= 0 days?) this kind of policy would work, but it would require administrator= s to check monthly both their primary and backup pins, otherwise the recove= ry plan above won't work. Yoav From tobias.gondrom@gondrom.org Thu Aug 15 08:38:21 2013 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 6962A11E81B7 for ; Thu, 15 Aug 2013 08:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgGjSKkoB95W for ; Thu, 15 Aug 2013 08:38:16 -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 8C78E11E81D2 for ; Thu, 15 Aug 2013 08:38:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=CNtMVibHBr+lVvc7PeMhfvqgrAJ6397FyP9iQs1qwBKq1CCLJMvSN/cqMqvfQ10ZiXLpf5qEwl6SzQBpNUm3pLxu0TS+dkMyOvRHBUgoqhj8mjKFljXQvJzahh0hkvxg; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 26448 invoked from network); 15 Aug 2013 17:37:58 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.64?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 15 Aug 2013 17:37:58 +0200 Message-ID: <520CF5D5.20008@gondrom.org> Date: Thu, 15 Aug 2013 16:37:57 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: ynir@checkpoint.com References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <52089A35.9040103@mozilla.org> <52091598.7000306@mozilla.org> <5209FF9D.1080208@mozilla.org> <520C166E.7000202@mozilla.org> <520C91B3.20402@mozilla.org> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 15 Aug 2013 15:38:21 -0000 On 15/08/13 16:19, Yoav Nir wrote: > On Aug 15, 2013, at 12:08 PM, Trevor Perrin wrote: > >> On Thu, Aug 15, 2013 at 1:30 AM, Gervase Markham wrote: >>> On 15/08/13 09:20, Trevor Perrin wrote: >>>> So you're expecting sites to edit their HPKP header on every cert >>>> change? >>> No; it's quite possible that the advice on renew would be "keep the same >>> pins". >> OK. So you're expecting sites to request a new cert at least T days >> prior to their existing cert expiring (where T is the length of time >> needed for extant pins to expire). > That would require either the sites to buy more certs than they need (and have overlapping certs) or the CAs to issue future certs (notBefore date T days in the future) and commit to the pinning data being valid for (validity_period + T). Not rocket science, but somewhat error prone. > > OTOH if the site administrator pins the EE public key, they don't need to involve the CA at all. They just need to generate the key pair (or the certificate request) T days in advance, and add the new pin to the HPKP header/resource. > > If someone were to ask me what a good pinning policy would be, I would say that they need three pins most of the time: > 1. for the EE certificate > 2. for the current root CA > 3. for some other root CA (that you trust) > > If the EE certificate is compromised, you issue a new one from the current root CA, and update the pin. > If the CA gets compromised, you issue a new cert from the backup root CA and update the pin (also with a new backup) > T days before expiry, you generate a certreq, and add the new public key as a fourth pin until you change the certificate. > > The pinning idea became cool because static pinning caught the Diginotar breach. A policy like this would detect fake certificates (as long as Diginotar was not your primary or backup CA). > > If CAs publish pin data on their website and guarantee that they will put any change on their website at least x days before the change takes place (90 days?) this kind of policy would work, but it would require administrators to check monthly both their primary and backup pins, otherwise the recovery plan above won't work. Actually the CA could also use an email push service instead of or in addition to the website publication. > Yoav > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From ynir@checkpoint.com Thu Aug 15 09:16:24 2013 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 99F8C21E80A1 for ; Thu, 15 Aug 2013 09:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.543 X-Spam-Level: X-Spam-Status: No, score=-10.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fomMPBeqn8Yv for ; Thu, 15 Aug 2013 09:16:18 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id DC89421E8084 for ; Thu, 15 Aug 2013 09:16:13 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7FGG9BO028884; Thu, 15 Aug 2013 19:16:09 +0300 X-CheckPoint: {520CFEC9-14-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Thu, 15 Aug 2013 19:16:08 +0300 From: Yoav Nir To: Tobias Gondrom Thread-Topic: [websec] #58: Should we pin only SPKI, or also names Thread-Index: AQHOjHagv3/BmvZ4wU6WrbkIw+Bd/ZmAXZOAgAADk4CAAHu6gIAIRDGAgAJ+5gCAA6qMgIAB0yuAgACEa4CAAA6sAIAAYXWAgACClYCAADLvgIACEiGAgABrbACAAJAKAIAAAumAgAAKsYCAAGecgIAABRGAgAAKr4A= Date: Thu, 15 Aug 2013 16:16:08 +0000 Message-ID: <0C203D85-A82B-4CF3-8E36-7867B8803CB1@checkpoint.com> References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com> <2035FF99-A079-4F2F-B4DE-962FE1C1B964@checkpoint.com> <52089A35.9040103@mozilla.org> <52091598.7000306@mozilla.org> <5209FF9D.1080208@mozilla.org> <520C166E.7000202@mozilla.org> <520C91B3.20402@mozilla.org> <520CF5D5.20008@gondrom.org> In-Reply-To: <520CF5D5.20008@gondrom.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.3] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11682f0913d6093a13c4c77914d6b7dd01dfe1992d Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 15 Aug 2013 16:16:24 -0000 On Aug 15, 2013, at 6:37 PM, Tobias Gondrom wr= ote: > On 15/08/13 16:19, Yoav Nir wrote: >> On Aug 15, 2013, at 12:08 PM, Trevor Perrin wrote: >>=20 >>> On Thu, Aug 15, 2013 at 1:30 AM, Gervase Markham wro= te: >>>> On 15/08/13 09:20, Trevor Perrin wrote: >>>>> So you're expecting sites to edit their HPKP header on every cert >>>>> change? >>>> No; it's quite possible that the advice on renew would be "keep the sa= me >>>> pins". >>> OK. So you're expecting sites to request a new cert at least T days >>> prior to their existing cert expiring (where T is the length of time >>> needed for extant pins to expire). >> That would require either the sites to buy more certs than they need (an= d have overlapping certs) or the CAs to issue future certs (notBefore date = T days in the future) and commit to the pinning data being valid for (valid= ity_period + T). Not rocket science, but somewhat error prone. >>=20 >> OTOH if the site administrator pins the EE public key, they don't need t= o involve the CA at all. They just need to generate the key pair (or the ce= rtificate request) T days in advance, and add the new pin to the HPKP heade= r/resource. >>=20 >> If someone were to ask me what a good pinning policy would be, I would s= ay that they need three pins most of the time: >> 1. for the EE certificate >> 2. for the current root CA >> 3. for some other root CA (that you trust) >>=20 >> If the EE certificate is compromised, you issue a new one from the curre= nt root CA, and update the pin. >> If the CA gets compromised, you issue a new cert from the backup root CA= and update the pin (also with a new backup) >> T days before expiry, you generate a certreq, and add the new public key= as a fourth pin until you change the certificate.=20 >>=20 >> The pinning idea became cool because static pinning caught the Diginotar= breach. A policy like this would detect fake certificates (as long as Digi= notar was not your primary or backup CA). >>=20 >> If CAs publish pin data on their website and guarantee that they will pu= t any change on their website at least x days before the change takes place= (90 days?) this kind of policy would work, but it would require administra= tors to check monthly both their primary and backup pins, otherwise the rec= overy plan above won't work. > Actually the CA could also use an email push service instead of or in > addition to the website publication. They could, but occasionally the contact person at the customer's is someon= e who's left the company. Also, while the primary CA has your address, the = backup CA has no idea that it is the backup CA. But yes, a link with "sign = up for email updates regarding pinning data" would work. Yoav= From ryan-ietfhasmat@sleevi.com Thu Aug 15 12:19:04 2013 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 D73C521F9DCE for ; Thu, 15 Aug 2013 12:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHoUJMQ2WsjI for ; Thu, 15 Aug 2013 12:19:00 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 7A54021F9D8D for ; Thu, 15 Aug 2013 12:19:00 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id B56D91B406B; Thu, 15 Aug 2013 12:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :date:subject:from:to:cc:reply-to:mime-version:content-type: content-transfer-encoding; s=sleevi.com; bh=i+e2EKxP/e3VJcDg0ITq HytQ7+U=; b=PKfyBX4RgtXWlz6bK8MLcudbNeH40u0yqOuternl/tA/7Onel3dn tCWjxs8SocY5lgmF3uwF0b5IAD2m5H8wbmiMAN+OQJTFkX+NdvALsG9lK1q90oZ2 pUtMQWxIPJXKbNSVHTNya0p10P2nukQ3fkeaznr2RYwqvftu6OfFUTQ= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPA id 958441B4061; Thu, 15 Aug 2013 12:18:37 -0700 (PDT) Received: from 216.239.45.93 (proxying for 216.239.45.93) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Thu, 15 Aug 2013 12:18:37 -0700 Message-ID: <0083f4e5b41f83576e57949e981deef9.squirrel@webmail.dreamhost.com> Date: Thu, 15 Aug 2013 12:18:37 -0700 From: "Ryan Sleevi" To: "Trevor Perrin" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 19:19:05 -0000 On Thu, August 15, 2013 1:20 am, Trevor Perrin wrote: > On Wed, Aug 14, 2013 at 4:44 PM, Gervase Markham wr= ote: > > On 14/08/13 18:20, Trevor Perrin wrote: > >> My point is that changes like CAs issuing new intermediates or > >> deprecating old roots MUST get incorporated into website pins someho= w. > > > > Perhaps this is the point of disagreement. > > > > I would expect CAs to offer appropriate pinning advice with > > certificates, probably in the form of "paste this into your HPKP > > header". Once a cert is in use and pinned, no further changes to thos= e > > pins need to be made. > > So you're expecting sites to edit their HPKP header on every cert > change? In that case I'd expect them to pin their end-entity key (see > reasons below). I believe they'd have to edit the HPKP header twice: > * Add their next end-entity key to the HPKP header > * Wait for time T (where T is sufficient for all older pins to expire= ) > * Switch to certificates with the new key > * Once the switch is complete, delete the old key from the HPKP heade= r > > Sound right? > > > > No matter what happens to the CA's business, as > > long as the root and intermediate you are using are still valid (and, > > absent a CA breach, they will be - no CA sells certs which use roots = and > > intermediates which expire before the cert finishes its lifetime), yo= u > > don't have to worry. When you get a new cert (renewal), you'll get > > updated pinning advice. > > In a strict sense I don't think this is true. You're assuming every > end-entity cert "uses" a single root, which is constant for the > lifetime of the cert absent a CA breach. > > But HPKP pins are checked against the browser-constructed cert path, > which might contain intermediates and roots different from what the > website sent, or thinks its "using". > > Example: You pin what you think is the root cert of your current > certificate. 3 months later the intermediate is upgraded to a root in > the browser's trust store, or becomes cross-certified by a different > root. Your pin fails, as the browser no longer constructs paths that > use the pinned root. > > See Ryan's explanation of AIA chasing for more on this [1]. > > While pinning the end-entity's immediate-parent intermediate doesn't > have this problem, I don't see that it has any advantage over pinning > the end-entity key directly. Regardless of what the website sends, there is no question that there is = a single authoritative source for all possible paths - this is the CA themselves. I think you're presuming a model where the site operator must work to independently discover every path possible, I don't think that's the goal at all. This is something that the CA can inform their customers of the pinning information. The CA knows what roots they have that exist (as they've been audited and part of their CPS), they know what plans they have for the issuance of new intermediates or the deprecation of older intermediates, and they can work to communicate that to customers. I think the argument that "browsers will be more effective at this" entirely disregards one of the (many) motivations for pinning - namely, that site operators *don't want* to trust the browsers for their security policy. That is, it is directly because browsers treat all CAs as equal that a site operated in the US, by a US company, with a certificate from = a US CA, can be compromised by a small organization in the Netherlands. Pinning, in many ways, restores the balance by allowing the *site operator* the flexibility to state their security policy, with the input of their CA, independent of any browser coordination. I'm also not convinced that it's a reasonable assumption to assume that all other factors of the industry will remain constant with or without pinning. What I mean is that it's entirely reasonable to see CAs spin up special "pinning" roots, which the CA contractually agrees will experienc= e much less churn/turnover than their 'traditional' roots. For example, most intermediate re-issuance by CAs is done in order to kee= p CRLs small or to make modifications of policies. A CA may offer a class o= f "pinning" certs specifically designed such that the frequency of these events is minimized. It's a perfectly reasonable market tradeoff. Perhaps this will be an extra cost, commisserate to the presumed support costs in configuring this, or perhaps it will be a free service, as each pinning reflects a customer's endorsement of a given CA's security policies and practices. I see the problems you're raising regarding SPKI as being solvable by means other than technical, whereas the whole notion of pinning by CA nam= e opens up a whole host of new problems that can *only* be solved with increasingly complicated technical solutions and that serve to *remove* control from site operators, and *increase* the implementation hurdles to implementors - making it unattractive to both parties. There is an extreme benefit to SPKI in that it's entirely unambiguous and is stable throughout the lifetime of a cert, whereas a CA naming scheme has been shown to be both ambiguous and unstable. That's not to say I think they're unsolvable problems, but I equally don'= t think it's necessary to solve them now, as I believe pinning via SPKI still offers a viable path forward, with multiple possible solutions to some of the problems you've raised here. > > > > If you have pinned a backup provider, you will no doubt have sought > > similar pinning advice from them. There is more of a risk that this > > advice will need to change at a different time from you changing your > > cert, but that's OK, because you can change this stuff as much as you > > like and all you have to do is wait for caches to empty (30 days?). > > Well, you *can* change your HPKP header as much as you like, but do > you want to? If you pin several CAs, and find yourself having to edit > the HPKP header multiple times a year, isn't that kind of a hassle? > > My point was not that it's impossible for websites to track CA key > lists, just that it would be more user-friendly if they didn't have > to. > > > Trevor > > > [1] http://www.ietf.org/mail-archive/web/websec/current/msg01425.html > From ietf-secretariat-reply@ietf.org Thu Aug 15 10:31:06 2013 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 585C111E81E9 for ; Thu, 15 Aug 2013 10:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.444 X-Spam-Level: X-Spam-Status: No, score=-101.444 tagged_above=-999 required=5 tests=[AWL=-1.063, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBb2IeSqIC3X; Thu, 15 Aug 2013 10:31:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DF611E81F3; Thu, 15 Aug 2013 10:31:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: websec-chairs@tools.ietf.org, draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130815173104.2194.53188.idtracker@ietfa.amsl.com> Date: Thu, 15 Aug 2013 10:31:04 -0700 From: IETF Secretariat X-Mailman-Approved-At: Fri, 16 Aug 2013 08:07:11 -0700 Subject: [websec] ID Tracker State Update Notice: 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, 15 Aug 2013 17:31:06 -0000 State changed to IESG Evaluation::AD Followup from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-o= ptions/ From trevp@trevp.net Fri Aug 16 09:06:20 2013 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 3858521F9E28 for ; Fri, 16 Aug 2013 09:06:20 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaS-RGEI48Y5 for ; Fri, 16 Aug 2013 09:06:02 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8208E11E8152 for ; Fri, 16 Aug 2013 09:06:00 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b13so1699530wgh.31 for ; Fri, 16 Aug 2013 09:05:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BotTUbVaNguvJTnftpes1JrSaT8wKCBqI11JrwUvGnM=; b=Mg3pGiBvxxmlnGviFu7tTRo8RO2X/AWFefJIVz1rtZyYlWSsVAeAuZxOK9Pi1GVLre ffhCekoY0p7izA2ktvL/8XiG5lqNAlqKBDPYYVdfzwrSjGZjMtHvhrmuwtLQgnMlp9lv ZuC6ZWxP2vS7EcvlH95NSJ7O9GkZjrGlFgnBpFRBKDa3di/ezWlq8X56sT2LJK4HMjUP Q0UyIo9wVMkLIJD+NLSzMgVV1hUDhV+3IAWaib85BqWeo5sB7WVnQhuu7IbrSZr6q40w M4JO0YvT7ktLJ3je/zugIeDLFrJ8xpSiATIHyEQ/+BsxrNx5+eWfhIuddB5eDtKipJ9Q qv5w== X-Gm-Message-State: ALoCoQmhZXvH/M9lIHVhDQ+n2fQnK0/Pj12s7UHDSRiJQWDBrsU/z0JycVlhwzV5X1hygU5Z6Wea MIME-Version: 1.0 X-Received: by 10.180.97.226 with SMTP id ed2mr5711572wib.17.1376669157143; Fri, 16 Aug 2013 09:05:57 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Fri, 16 Aug 2013 09:05:57 -0700 (PDT) X-Originating-IP: [199.83.223.81] In-Reply-To: <0083f4e5b41f83576e57949e981deef9.squirrel@webmail.dreamhost.com> References: <0083f4e5b41f83576e57949e981deef9.squirrel@webmail.dreamhost.com> Date: Fri, 16 Aug 2013 09:05:57 -0700 Message-ID: From: Trevor Perrin To: ryan-ietfhasmat@sleevi.com Content-Type: text/plain; charset=ISO-8859-1 Cc: websec Subject: Re: [websec] #58: Should we pin only SPKI, or also names 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, 16 Aug 2013 16:06:21 -0000 On Thu, Aug 15, 2013 at 12:18 PM, Ryan Sleevi wrote: > > I think you're presuming a model where the site operator must work to > independently discover every path possible, I don't think that's the goal > at all. This is something that the CA can inform their customers of the > pinning information. Sure, we'd definitely like CAs to inform customers of root pinning changes. My point was narrower: These changes may occur either synchronously or asynchronously with new cert issuance. I.e. you may go to renew a cert, and be informed that using it will require a pinning change. But you might also get a cert with a 2-year validity period, and a year into it the CA informs you that a pinning change will be required in a few months. > I think the argument that "browsers will be more effective at this" > entirely disregards one of the (many) motivations for pinning - namely, > that site operators *don't want* to trust the browsers for their security > policy. I'd distinguish between policy decision and enforcement. Certainly we want to let sites decide their policy. But I'd argue that once a site has decided on, say, a "symantec, comodo, godaddy" pinning policy, mapping this to a set of keys is a matter of enforcement which it would be reasonable to trust browsers with. I'd also argue that the more HPKP enables sites to focus on simply declaring a CA policy instead of grappling with implementation details such as multi-step update processes, the more useable and successful this will be. > I'm also not convinced that it's a reasonable assumption to assume that > all other factors of the industry will remain constant with or without > pinning. What I mean is that it's entirely reasonable to see CAs spin up > special "pinning" roots, which the CA contractually agrees will experience > much less churn/turnover than their 'traditional' roots. That would be great. > There is an extreme benefit to SPKI in that it's entirely unambiguous and > is stable throughout the lifetime of a cert, whereas a CA naming scheme > has been shown to be both ambiguous and unstable. An SPKI pin is not necessarily stable through the lifetime of a cert. Because pinning to SPKIs is rigidly fixed to a set of keys, it's more likely to need changes, and thus - from the website's perspective - less stable than a more "ambiguous" and flexible named pin. The more compelling argument, for me, is that named pins have been shown to be a lot more work, and we're not really sure how / where to coordinate it. > That's not to say I think they're unsolvable problems, but I equally don't > think it's necessary to solve them now, as I believe pinning via SPKI > still offers a viable path forward, with multiple possible solutions to > some of the problems you've raised here. I think it's reasonable to move forward in that way - best not enemy of the good, etc., and there's plenty of new things to deploy here and get comfortable with before adding more. Trevor From bhill@paypal-inc.com Fri Aug 16 14:53:02 2013 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 858CA11E815B; Fri, 16 Aug 2013 14:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDbbBPIjefjZ; Fri, 16 Aug 2013 14:52:56 -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 8325A11E80EA; Fri, 16 Aug 2013 14:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=@paypal-inc.com; q=dns/txt; s=paypalcorp; t=1376689972; x=1408225972; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8Sc7FM7Kznm0RGhtJjNZdQ50yL3xx3xv2m1s6y1WYoc=; b=udsxAhbkpBp6Wf1ThcCVyUFtCiMA0lFo68HsyHhpjpJ/0Cafqt3Q4x59 PoC/y3zlGROUBVVLOrmALIkOqUZGvszkZRYovdWO8mcIuXJk28OjbRa8e TLB/0wlRC/oa9SpbdSYqRVgd0r/BoBEsNnTEqQU50GlfRSO7euZsxvZwv s=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.89,897,1367996400"; d="scan'208";a="20106958" Received: from den-vteml-001.corp.ebay.com (HELO DEN-EXMHT-003.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 16 Aug 2013 14:52:51 -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.03.0123.003; Fri, 16 Aug 2013 15:52:50 -0600 From: "Hill, Brad" To: Tobias Gondrom , "barryleiba@computer.org" , "turners@ieca.com" Thread-Topic: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) Thread-Index: AQHOmQvZvhjSxObzHEuQHwRVbSMHKJmVTMaAgAMWhLA= Date: Fri, 16 Aug 2013 21:52:50 +0000 Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E27BACF3D@DEN-EXDDA-S12.corp.ebay.com> References: <20130814161444.6218.82572.idtracker@ietfa.amsl.com> <520BB341.3050209@gondrom.org> In-Reply-To: <520BB341.3050209@gondrom.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.245.27.241] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned den1 Cc: "draft-ietf-websec-x-frame-options@tools.ietf.org" , "websec@ietf.org" , "iesg@ietf.org" , "websec-chairs@tools.ietf.org" Subject: Re: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 16 Aug 2013 21:53:02 -0000 From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf Of= Tobias Gondrom Sent: Wednesday, August 14, 2013 9:42 AM To: barryleiba@computer.org; turners@ieca.com Cc: draft-ietf-websec-x-frame-options@tools.ietf.org; websec@ietf.org; iesg= @ietf.org; websec-chairs@tools.ietf.org Subject: Re: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-op= tions-09: (with DISCUSS and COMMENT) On 14/08/13 17:30, Barry Leiba wrote: It's interesting to note that this draft says there's a problem with folks not checking the origins of the entire ancestor tree of names of the framing resource - but then doesn't say that sounds like a good idea do it. I can see the argument that might be made that this draft is just documenting what's done now, but shouldn't we take the opportunity to do more and recommend something along the lines of "The entire ancestor tree of names of the framing resource SHOULD be checked to mitigate the risk of attacks in multiple-nested scenarios" or something like that? It seems that that should be work for the W3C folks who are working on the successor mechanism. This really *is* just meaning to document what's in use now, warts and all. Barry I agree with Barry.=20 (And we gave according input to WebAppSec at W3C when we handed over the go= al for CSP1.1.) Best regards, Tobias ----------------- And the ancestor walking behavior is what we have specified in the success= or at W3C. -Brad Hill From bhill@paypal-inc.com Fri Aug 16 16:44:24 2013 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 7A8E911E80E8; Fri, 16 Aug 2013 16:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJlloSAxXM0e; Fri, 16 Aug 2013 16:44:20 -0700 (PDT) Received: from rhv-mipot-001.corp.ebay.com (rhv-mipot-001.corp.ebay.com [216.33.244.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBDB21F9F8F; Fri, 16 Aug 2013 16:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=@paypal-inc.com; q=dns/txt; s=paypalcorp; t=1376696660; x=1408232660; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rsR1GLqgluZU+KxbfWjt9XxXTYtiT0bPrmjAo5u2rHo=; b=cv30hVXrMWdAcaKXdIwJdeeO4d58TZ/d1rE9CSrOm062JeGClDDODbvm 1oCzYq/ghl6bj6XUErg+dRtNGI7KHMGe5iFRNPpf1dYj00SzCQHBTe8aX dt1pgkZhq0T3/jIunSobauRY1XU+Caf7bttg8HhuO3ePAQ2EHhihPqvwG w=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.89,898,1367996400"; d="scan'208";a="139159913" Received: from rhv-vtenf-001.corp.ebay.com (HELO DEN-EXMHT-005.corp.ebay.com) ([10.112.113.52]) by rhv-mipot-001.corp.ebay.com with ESMTP; 16 Aug 2013 16:44:18 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-005.corp.ebay.com ([fe80::8109:2a37:17ad:e57e%18]) with mapi id 14.03.0123.003; Fri, 16 Aug 2013 17:44:17 -0600 From: "Hill, Brad" To: Richard Barnes , The IESG Thread-Topic: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) Thread-Index: AQHOmVir9vsxQULiiEyJJmzuP9qAZ5mYgLPG Date: Fri, 16 Aug 2013 23:44:16 +0000 Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E27BAD2A7@DEN-EXDDA-S12.corp.ebay.com> References: <20130815014121.17800.33179.idtracker@ietfa.amsl.com> In-Reply-To: <20130815014121.17800.33179.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.241.19.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-websec-x-frame-options@tools.ietf.org" , "websec@ietf.org" , "websec-chairs@tools.ietf.org" Subject: Re: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 16 Aug 2013 23:44:24 -0000 Additional comments inline.=0A= ________________________________________=0A= =0A= =0A= (D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI? In other=0A= words, what does it mean to send "X-Frame-Options: ALLOW-FROM=0A= https://example.com/this/is/a/path?query#fragment"?=0A= =0A= [Hill, Brad] Agreed.=0A= =0A= =0A= (D3) In the ALLOW-FROM: what does "top level context" mean? Do you=0A= really mean the top level here, as opposed to the next one up? For=0A= example, suppose A loads B in an iframe, and B loads C, and then C sends=0A= an X-Frame-Options header with ALLOW-FROM. Is the ALLOW-FROM origin=0A= compared to B or A? In either case, you should also note the attacks=0A= that remain. For example, if the answer is B, then B needs to use=0A= X-Frame-Options as well, or else, A can maliciously frame A within B. Or= =0A= if the answer is A, then C is trusting A not to load any malicious=0A= intermediate frames B.=0A= =0A= [Hill, Brad] This really does mean the top/final origin value in a frame a= ncestor=0A= chain walk. Browsers have implemented X-Frame-Options to check the =0A= Origin context that is topmost in the window or tab. (the _top target, =0A= representing the full, original browsing context, not just the immediate = =0A= parent frame) This could be clarified perhaps, but is not incorrect.=0A= =0A= From tobias.gondrom@gondrom.org Sat Aug 17 11:57:45 2013 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 2FA7111E821A for ; Sat, 17 Aug 2013 11:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.361 X-Spam-Level: X-Spam-Status: No, score=-95.361 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soBxSYcOVyDp for ; Sat, 17 Aug 2013 11:57: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 B8CE411E8218 for ; Sat, 17 Aug 2013 11:57:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=CGuo670Mmsa75cu5EBznXVYvmxSZCSq37x+Y1uBCvYOBq6uQpaZcfFo3XgcUiQCX4gfL6dNcoiUX9j3nRzGVWf+K3ojst/dcXn4N8JLXjfkFmvCMzW/O0SFoPN4sQeb1; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Priority:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 21710 invoked from network); 17 Aug 2013 20:57:35 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.64?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 17 Aug 2013 20:57:35 +0200 Message-ID: <520FC79E.9090201@gondrom.org> Date: Sat, 17 Aug 2013 19:57:34 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: barryleiba@computer.org X-Priority: 4 (Low) References: <20130814221250.16821.99472.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------090107090507030705060607" Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, presnick@qti.qualcomm.com, websec@ietf.org, iesg@ietf.org, websec-chairs@tools.ietf.org Subject: Re: [websec] Pete Resnick's No Objection on draft-ietf-websec-x-frame-options-09: (with COMMENT) 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, 17 Aug 2013 18:57:46 -0000 This is a multi-part message in MIME format. --------------090107090507030705060607 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 14/08/13 23:15, Barry Leiba wrote: >> Why is this document not on the standards track? > Because it's not anything we want to tell people to start implementing > now. We want them to move toward the work we transferred over to > W3C's WebAppSec group instead. > > b > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec Barry is correct. Best regards, Tobias --------------090107090507030705060607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 14/08/13 23:15, Barry Leiba wrote:
Why is this document not on the standards track?

Because it's not anything we want to tell people to start implementing
now.  We want them to move toward the work we transferred over to
W3C's WebAppSec group instead.

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

Barry is correct.

Best regards, Tobias

 --------------090107090507030705060607-- From tobias.gondrom@gondrom.org Sat Aug 17 12:23:40 2013 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 B0CFE11E824A for ; Sat, 17 Aug 2013 12:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.361 X-Spam-Level: X-Spam-Status: No, score=-95.361 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 564j8e0eM1WQ for ; Sat, 17 Aug 2013 12:23:35 -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 32E7511E8218 for ; Sat, 17 Aug 2013 12:23:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=Ibp6T/nglpl1Lrqj4oGDSzNRvvXPtZ2f8fJEYiS0xoQucN33r7jcDkQp3IiHYuPQFPIXffwozjN43M2mz6EaMM6IP1IvzeY2AH5Z+zPC4JqetFzkw8emtqNhTOsBCHt1; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 22015 invoked from network); 17 Aug 2013 21:23:33 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.64?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 17 Aug 2013 21:23:33 +0200 Message-ID: <520FCDB4.6050802@gondrom.org> Date: Sat, 17 Aug 2013 20:23:32 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: presnick@qti.qualcomm.com References: <20130814221250.16821.99472.idtracker@ietfa.amsl.com> <520C493C.9080208@qti.qualcomm.com> In-Reply-To: <520C493C.9080208@qti.qualcomm.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------050508050600020406070107" Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, barryleiba@computer.org, websec@ietf.org, iesg@ietf.org, websec-chairs@tools.ietf.org Subject: Re: [websec] Pete Resnick's No Objection on draft-ietf-websec-x-frame-options-09: (with COMMENT) 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, 17 Aug 2013 19:23:40 -0000 This is a multi-part message in MIME format. --------------050508050600020406070107 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 15/08/13 04:21, Pete Resnick wrote: > On 8/14/13 5:15 PM, Barry Leiba wrote: >>> Why is this document not on the standards track? >>> >> Because it's not anything we want to tell people to start implementing >> now. We want them to move toward the work we transferred over to >> W3C's WebAppSec group instead. >> > > It's probably worth having a line to that effect somewhere in the > document. > > pr > We do have a respective text in the introduction: "This specification provides informational documentation about the current use and definition of the X-Frame-Options HTTP header field. As described in Section 2.3.2.2 not all browsers implement X-Frame-Options exactly in the sames way, which can lead to unintended results. And given that the "X-" construction is deprecated [RFC6648], the X-Frame-Options header field will in the future be replaced by the Frame-Options directive in the Content Security Policy Version 1.1 [CSP-1-1]" Best regards, Tobias --------------050508050600020406070107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 15/08/13 04:21, Pete Resnick wrote:
On 8/14/13 5:15 PM, Barry Leiba wrote:
Why is this document not on the standards track?
    
Because it's not anything we want to tell people to start implementing
now.  We want them to move toward the work we transferred over to
W3C's WebAppSec group instead.
  

It's probably worth having a line to that effect somewhere in the document.

pr

We do have a respective text in the introduction:
"This specification provides informational documentation about the current use and definition of the X-Frame-Options HTTP header field. As described in Section 2.3.2.2 not all browsers implement X-Frame-Options exactly in the sames way, which can lead to unintended results. And given that the "X-" construction is deprecated [RFC6648], the X-Frame-Options header field will in the future be replaced by the Frame-Options directive in the Content Security Policy Version 1.1 [CSP-1-1]"

Best regards, Tobias


--------------050508050600020406070107-- From tobias.gondrom@gondrom.org Sat Aug 17 12:31:22 2013 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 8654D11E8209 for ; Sat, 17 Aug 2013 12:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KF4ulfgPuOR8 for ; Sat, 17 Aug 2013 12:31:18 -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 B56E221F9C12 for ; Sat, 17 Aug 2013 12:31:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=ZEaW2iQoJmFRGwKcbno9PjZczJywC338gdVbssXjWFXG4KfgkfoWdASruGmL4nIz6nlP4nc/x1+gr4r8gCE8GMFgh2EAZKZix0Dqd6tBRcJVQz0vpieBSTbq10ysrchr; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 22087 invoked from network); 17 Aug 2013 21:31:16 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.64?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 17 Aug 2013 21:31:16 +0200 Message-ID: <520FCF84.9010605@gondrom.org> Date: Sat, 17 Aug 2013 20:31:16 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: stephen.farrell@cs.tcd.ie References: <20130814224803.25993.58131.idtracker@ietfa.amsl.com> In-Reply-To: <20130814224803.25993.58131.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, iesg@ietf.org, websec-chairs@tools.ietf.org Subject: Re: [websec] Stephen Farrell's Yes on draft-ietf-websec-x-frame-options-09: (with COMMENT) 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, 17 Aug 2013 19:31:22 -0000 On 14/08/13 23:48, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-websec-x-frame-options-09: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > (Personal opinion only, no change requested unless it > resonates with folks.) I would prefer that this not say > that NoScript impairs broswer utility. I find it fine. > > Other than that, this is a fine draft, thanks. > Stephen, personally, I use NoScript, too. But, looking at todays web applications JavaScript and frames are widely spread and many web applications would indeed be very impaired if you disable JavaScript and frames in your browser entirely. Some years ago people tried to discourage JavaScript for security sensitive applications (read "most of the web applications") and to disable JavaScript in the browser, but meanwhile we moved past that point and try to fix the security/trust models for JavaScript using CSP - which I hope gives us another chance to fix large parts of it). JavaScript functions are quite common nowadays in airline booking systems, banking, corporate websites, etc. Be it for design, client side input validation or other interactive functionality up to editing capabilities. Best regards, Tobias From barryleiba@gmail.com Sat Aug 17 13:01:15 2013 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 7FCC811E8186; Sat, 17 Aug 2013 13:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.952 X-Spam-Level: X-Spam-Status: No, score=-101.952 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tpew3PDrXJi2; Sat, 17 Aug 2013 13:01:14 -0700 (PDT) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8D29C11E814C; Sat, 17 Aug 2013 13:01:14 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 3so188134qea.21 for ; Sat, 17 Aug 2013 13:01:10 -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:message-id:subject :from:to:cc:content-type; bh=8Jsid2FPwAbOKOruYhhSzmvTBjhQ6X0tQ2DYhwEW3vk=; b=mdYzo9Req3C7TAyGxSaWR5o9TvxDxLWQXHTSIMx+Rat3moe0i0NYpt2Xpj7fRiOk8k OvscBKLn+hh5xDmq2nX5iDU3QkbvPZ2FCorMroL+9QtJB94lPo4xmtTMO8wQ86gUHA6h zsVHBZFZUKMaCqpvcJKqQRMsbTF/wsD0t5l1lSVq75JWLfIBSiS00QTMzB9BXE1YPWBS 1leJlQ4z2GXuPKUkYEBZMGsXZtHqMhqnbbMhvMY1MvZqgFJMqaGMr0b3JS9KAK3sSEpP EPSfVzXx0L6doJDgOWtJNI693GrpGbB2ObnUqiQLD+IfOFvYpheo2YcDLivO/3IcrcL/ oysw== MIME-Version: 1.0 X-Received: by 10.224.54.210 with SMTP id r18mr4916266qag.62.1376769670614; Sat, 17 Aug 2013 13:01:10 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.59.211 with HTTP; Sat, 17 Aug 2013 13:01:10 -0700 (PDT) In-Reply-To: <520FCF84.9010605@gondrom.org> References: <20130814224803.25993.58131.idtracker@ietfa.amsl.com> <520FCF84.9010605@gondrom.org> Date: Sat, 17 Aug 2013 16:01:10 -0400 X-Google-Sender-Auth: XyAfx211GIZqLg7vCzV5Wi5YurU Message-ID: From: Barry Leiba To: Tobias Gondrom Content-Type: multipart/alternative; boundary=089e01537274279d9404e42a2b6d Cc: "websec-chairs@tools.ietf.org" , "draft-ietf-websec-x-frame-options@tools.ietf.org" , "websec@ietf.org" , "iesg@ietf.org" Subject: Re: [websec] Stephen Farrell's Yes on draft-ietf-websec-x-frame-options-09: (with COMMENT) 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, 17 Aug 2013 20:01:15 -0000 --089e01537274279d9404e42a2b6d Content-Type: text/plain; charset=ISO-8859-1 Indeed. Really, the bottom line here is that things such as NoScript work we'll for us geeks, who know how to deal with the failures and exceptions, but they are horrid user experiences for people like my mother. Barry On Saturday, August 17, 2013, Tobias Gondrom wrote: > On 14/08/13 23:48, Stephen Farrell wrote: > > Stephen Farrell has entered the following ballot position for > > draft-ietf-websec-x-frame-options-09: Yes > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > > > (Personal opinion only, no change requested unless it > > resonates with folks.) I would prefer that this not say > > that NoScript impairs broswer utility. I find it fine. > > > > Other than that, this is a fine draft, thanks. > > > > Stephen, > personally, I use NoScript, too. > > But, looking at todays web applications JavaScript and frames are widely > spread and many web applications would indeed be very impaired if you > disable JavaScript and frames in your browser entirely. > Some years ago people tried to discourage JavaScript for security > sensitive applications (read "most of the web applications") and to > disable JavaScript in the browser, but meanwhile we moved past that > point and try to fix the security/trust models for JavaScript using CSP > - which I hope gives us another chance to fix large parts of it). > JavaScript functions are quite common nowadays in airline booking > systems, banking, corporate websites, etc. Be it for design, client side > input validation or other interactive functionality up to editing > capabilities. > > Best regards, Tobias > > > > > --089e01537274279d9404e42a2b6d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Indeed. =A0Really, the bottom line here is that things such as NoScript wor= k we'll for us geeks, who know how to deal with the failures and except= ions, but they are horrid user experiences for people like my mother.

Barry

On Saturday, August 17, 2013, Tobi= as Gondrom wrote:
On 14/08/13 23:48, Ste= phen Farrell wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-websec-x-frame-options-09: Yes
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss= -criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-webse= c-x-frame-options/
>
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
>
> (Personal opinion only, no change requested unless it
> resonates with folks.) I would prefer that this not say
> that NoScript impairs broswer utility. I find it fine.
>
> Other than that, this is a fine draft, thanks.
>

Stephen,
personally, I use NoScript, too.

But, looking at todays web applications JavaScript and frames are widely spread and many web applications would indeed be very impaired if you
disable JavaScript and frames =A0in your browser entirely.
Some years ago people tried to discourage JavaScript for security
sensitive applications (read "most of the web applications") and = to
disable JavaScript in the browser, but meanwhile we moved past that
point and try to fix the security/trust models for JavaScript using CSP
- which I hope gives us another chance to fix large parts of it).
JavaScript functions are quite common nowadays in airline booking
systems, banking, corporate websites, etc. Be it for design, client side input validation or other interactive functionality up to editing
capabilities.

Best regards, Tobias




--089e01537274279d9404e42a2b6d-- From tobias.gondrom@gondrom.org Sat Aug 17 15:46:12 2013 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 7182411E81A3 for ; Sat, 17 Aug 2013 15:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrR8ud+sWlIp for ; Sat, 17 Aug 2013 15:46:07 -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 E485C21F9935 for ; Sat, 17 Aug 2013 15:45:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=fOvp1GtYd7cmgm0NhABtxd1RXC+mZwW0ap0h97ZBoE0ZMBS9yxk248oxVz2se7ERedkT61WSTwCWAbhi9BZILVWDhnDpAalqUZy58zPH6QCyT5EIfassImbEF3Q1OFBU; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 24198 invoked from network); 18 Aug 2013 00:45:31 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.64?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Aug 2013 00:45:31 +0200 Message-ID: <520FFD0B.5040504@gondrom.org> Date: Sat, 17 Aug 2013 23:45:31 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: ted.lemon@nominum.com References: <20130814175121.16080.58938.idtracker@ietfa.amsl.com> <520BF1AB.5000103@gondrom.org> <0B70B4E8-0375-414F-B529-52D3EE0E275B@nominum.com> In-Reply-To: <0B70B4E8-0375-414F-B529-52D3EE0E275B@nominum.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, iesg@ietf.org, websec-chairs@tools.ietf.org Subject: Re: [websec] Ted Lemon's No Objection on draft-ietf-websec-x-frame-options-09: (with COMMENT) 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, 17 Aug 2013 22:46:12 -0000 On 14/08/13 22:49, Ted Lemon wrote: > On Aug 14, 2013, at 5:07 PM, Tobias Gondrom wrote: >> I had the hope with referring to RFC6454 this should be unambiguous and >> clear enough. I had the hesitation to write redundant text, but maybe I >> got too short. Do you think we need to spell it out more explicitly in >> the draft so people understand? > How about: > > Existing implementations differ with [RFC6454] in that origins with > the same protocol but different port values are considered equivalent. Ok. I added the sentence you suggested in version-10 as: "I.e. existing implementations differ with [RFC6454] in that origins with the same protocol but different port values are considered equivalent." > >>> What is the distinction between "top-level browsing context" and "origin >>> of the framing page?" A reference here would be helpful. >> Apologies. In this case I have hesitations to add an explanation about >> the nesting of frames in html. In general the concept of nested frames >> (and top-level vs. framing page) is reasonably understood. >> [will keep the text as is until I hear an argument that this really >> needs an explanation in this draft.] > The additional text that you added in your reply helps a little—it appears that "top-level browsing context" means "the HTML that is loaded first and that contains whatever nesting might occur" and perhaps that "origin of the framing page" refers somehow to the idea of nested frames. But even with the help you've given me in your reply, I am not sure that I have this right, and indeed I am scratching my head trying to figure out what the difference is between these two contexts. > > As a person who writes HTML fairly regularly, I think I am your intended target audience. If so, you really do need to explain what these terms mean, or provide a reference to a document that explains them. > Ok. And I noted that Richard raised a related question. So I added more text regarding the nesting of frames in section 2.3.2.3. From internet-drafts@ietf.org Sat Aug 17 15:46:13 2013 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 F30CF21F92B7; Sat, 17 Aug 2013 15:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKflutWIdtMv; Sat, 17 Aug 2013 15:46:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 356D921F9ADF; Sat, 17 Aug 2013 15:46:07 -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.70.p1 Message-ID: <20130817224607.20687.66846.idtracker@ietfa.amsl.com> Date: Sat, 17 Aug 2013 15:46:07 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-x-frame-options-10.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, 17 Aug 2013 22:46:13 -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 Header Field X-Frame-Options Author(s) : David Ross Tobias Gondrom Filename : draft-ietf-websec-x-frame-options-10.txt Pages : 13 Date : 2013-08-17 Abstract: To improve the protection of web applications against Clickjacking, this definition describes the X-Frame-Options HTTP response header field that declares a policy communicated from the server to the client browser on whether the browser may display the transmitted content in frames that are part of other web pages. This informational document serves to document the existing use and specification of this X-Frame-Options HTTP response header field. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-x-frame-options-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sat Aug 17 15:46:14 2013 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 0016A21F9ADF for ; Sat, 17 Aug 2013 15:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJy6tKgN7B9t; Sat, 17 Aug 2013 15:46:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9AE421F992E; Sat, 17 Aug 2013 15:46:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: websec-chairs@tools.ietf.org, draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, barryleiba@computer.org, rlb@ipv.sx, turners@ieca.com X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130817224607.20687.83342.idtracker@ietfa.amsl.com> Date: Sat, 17 Aug 2013 15:46:07 -0700 Subject: [websec] New Version Notification - draft-ietf-websec-x-frame-options-10.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, 17 Aug 2013 22:46:14 -0000 A new version (-10) has been submitted for draft-ietf-websec-x-frame-option= s: http://www.ietf.org/internet-drafts/draft-ietf-websec-x-frame-options-10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-x-frame-options-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From tobias.gondrom@gondrom.org Sat Aug 17 15:46:18 2013 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 C9CAC11E8257 for ; Sat, 17 Aug 2013 15:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGZ0vPDomh9m for ; Sat, 17 Aug 2013 15:46: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 55A3921F9B26 for ; Sat, 17 Aug 2013 15:46:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=pfwU8tCeIXt3wt18qIfPFDc3qZ7OItV+3kSSUL3mkCdJfnyDD1agGqlnl90mQBC8YEJjXgTTRAu/WI9neAm9QdARi51zWlAWbv2t5MVPb3UN/JLPrEjOinoGXGJMInn2; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 24246 invoked from network); 18 Aug 2013 00:45:45 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.64?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Aug 2013 00:45:45 +0200 Message-ID: <520FFD18.2010008@gondrom.org> Date: Sat, 17 Aug 2013 23:45:44 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: rlb@ipv.sx References: <20130815014121.17800.33179.idtracker@ietfa.amsl.com> In-Reply-To: <20130815014121.17800.33179.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, iesg@ietf.org, websec-chairs@tools.ietf.org Subject: Re: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 17 Aug 2013 22:46:19 -0000 Dear Richard, thanks for the review and your discusses and comments. Answers inline. I followed all your suggestions in version-10, except for D2. Thanks for the review and all the best, Tobias On 15/08/13 02:41, Richard Barnes wrote: > Richard Barnes has entered the following ballot position for > draft-ietf-websec-x-frame-options-09: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > (D1) The privacy considerations make no sense to me. To whom is data > being leaked? To the browser? To random people who send a request to a > URI? Do you mean that X-Frame-Options leaks information about who the > site authorizes? That's true, but also true of things like CORS. If > this is the concern, you should recommend a mitigation that's basically > the same as what CORS does, namely varying the value of X-Frame-Options > based on the Referer or Origin header. Yes. Ok. I expanded the text and explanation of the privacy considerations section accordingly. > > (D2) It seems like this is a value that browsers might cache, to avoid > unnecessary requests if the same page is framed in the future. If this > is something browsers do today, please say so. Actually I like to push back in this case, as I don't think we should go into implementation specific details that have no effect on the bits on the wire nor on the effective behavior of the browser. The X-Frame-Options header determines the behaviour for every individual requested page regarding framing in another web page in the browser. Whether the browser caches this information and compares the request with an existing cache from a request from before AND if the value is identical proceeds as before or whether the browser evaluates the X-Frame-Options header on each request should not be specified in this draft. > > (D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI? In other > words, what does it mean to send "X-Frame-Options: ALLOW-FROM > https://example.com/this/is/a/path?query#fragment"? Yes. You are right we can refine the definition to "serialized-origin" (as a subset of URI). Please note that according to RFC6454 we need to use "serialized-origin" here and not origin (as origin in RFC6454 refers also to a list of origins, which would not be acceptable here). I adjusted the text accordingly. Note: From an editorial standpoint we can debate whether to use lower case "serialized-origin" or capital "SERIALIZED-ORIGIN". RFC6454 uses lower case. So I used that one, but I am open for either. > > (D3) In the ALLOW-FROM: what does "top level context" mean? Do you > really mean the top level here, as opposed to the next one up? Yes. And unfortunately with the problems you outlined in the next sentence (which are also described in the security considerations sections of the draft.) Ted raised a related comment. So I guess the current text regarding nesting and potential problem is not sufficiently clear. So I will add further explanations. And I will add a reference to the security considerations section which already contains a paragraph about this problem. (i.e. the 2nd paragraph). > For > example, suppose A loads B in an iframe, and B loads C, and then C sends > an X-Frame-Options header with ALLOW-FROM. Is the ALLOW-FROM origin > compared to B or A? In either case, you should also note the attacks > that remain. For example, if the answer is B, then B needs to use > X-Frame-Options as well, or else, A can maliciously frame A within B. Or > if the answer is A, then C is trusting A not to load any malicious > intermediate frames B. I added text accordingly to section 5. (and I initiated a research query to re-confirm again that we still have the two inconsistent browser behaviour cases here (framing page vs. top-level frame, as I wrote in the draft). > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > (C1) In the Introduction, the phrase "secure web page" would seem to > imply that this mechanism only applies to pages delivered over HTTPS, > which I'm pretty sure isn't true. Suggest just deleting "secure". Ok. removed. > > (C2) In Section 2.1, the sentence starting "And the algorithm" seems to > imply that ALLOW-FROM allows SAMEORIGIN requests as well, which I think > you actually mean something like: > """ > And the algorithm to compare origins from [RFC6454] SHOULD be used to > verify that a referring page is of the same origin as the content (in the > case of SAMEORIGIN) or that the referring page's origin is identical with > the ALLOW-FROM URI (in the case of ALLOW-FROM). > """ Thank you. I changed the text to your suggestion. > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From tobias.gondrom@gondrom.org Sat Aug 17 15:48:06 2013 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 E7E2811E815F for ; Sat, 17 Aug 2013 15:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.361 X-Spam-Level: X-Spam-Status: No, score=-95.361 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLSPhbF5mQgD for ; Sat, 17 Aug 2013 15:48:02 -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 A0E0221F9C6B for ; Sat, 17 Aug 2013 15:47:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=oGXMr+H38SZ3veIhMkP17vgJ8hglsOUx0MVYlibC7zyUrNAcjdUniM4xguNOaw63thrrqzV+g8L75KazVat5iQ1f5uA2IgTy9TEpwhaCtp9LrmYkdSqPulk+uYQvNXWL; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 24369 invoked from network); 18 Aug 2013 00:47:57 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.64?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Aug 2013 00:47:57 +0200 Message-ID: <520FFD9D.2000401@gondrom.org> Date: Sat, 17 Aug 2013 23:47:57 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: joelja@bogus.com References: <20130815034155.27991.62074.idtracker@ietfa.amsl.com> In-Reply-To: <20130815034155.27991.62074.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------000308020208050002030306" Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, iesg@ietf.org, websec-chairs@tools.ietf.org Subject: Re: [websec] Joel Jaeggli's No Objection on draft-ietf-websec-x-frame-options-09: (with COMMENT) 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, 17 Aug 2013 22:48:07 -0000 This is a multi-part message in MIME format. --------------000308020208050002030306 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 15/08/13 04:41, Joel Jaeggli wrote: > Joel Jaeggli has entered the following ballot position for > draft-ietf-websec-x-frame-options-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > support richards discussion, the security/privacy considerations could > use some wordsmithing. > > Ok. As answered to Richard. Security and Privacy consideration sections have been expanded in version -10 Thanks for the review and all the best, Tobias --------------000308020208050002030306 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 15/08/13 04:41, Joel Jaeggli wrote:
Joel Jaeggli has entered the following ballot position for
draft-ietf-websec-x-frame-options-09: No Objection

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


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


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



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

support richards discussion, the security/privacy considerations could
use some wordsmithing.
Ok. As answered to Richard. Security and Privacy consideration sections have been expanded in version -10
Thanks for the review and all the best, Tobias


 --------------000308020208050002030306-- From barryleiba@gmail.com Sat Aug 17 22:58:57 2013 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 B5F8A11E824F; Sat, 17 Aug 2013 22:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.953 X-Spam-Level: X-Spam-Status: No, score=-101.953 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWuQvw+CEz3E; Sat, 17 Aug 2013 22:58:57 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB5211E821E; Sat, 17 Aug 2013 22:58:55 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id cr7so1253027qab.8 for ; Sat, 17 Aug 2013 22:58:54 -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:message-id:subject :from:to:cc:content-type; bh=iWNp1J3/Bvk50ikGIcHPk0EOmUuxoOvzQSdaalzJ1TQ=; b=djZz08z+7jK4U+MDb4dy+10elwJKhGDJep1Rh/zJOHJ0tk/h+W9qfv/8jNo6UuDGZf 53QMS5xEA7s1stvnoyu4vFm/KoQvRtP7EWT5CZNdsEvswXnaplIKvNVK16NvuAvBigpu sWIDnqPVEXzpYpu5+KRqe3FQO3GmI6g5QcAMR2oaG7LJRjzPckFjMoN/8snsEC0WWGLv gG95j0JUscfMePQslwqpg8C5Hn6NAjEPq4q8qLL9wX+v+hPwcWuyb+T4Dz9wsEgAR5qk L4Glf7nQbhOqgYNhZjxKqTwcfn+G8GP4o97/mpbUr6L4kRDrxKyPDzsy6fObXr5oRW+c e9Bw== MIME-Version: 1.0 X-Received: by 10.49.35.51 with SMTP id e19mr7135021qej.16.1376805533392; Sat, 17 Aug 2013 22:58:53 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.59.211 with HTTP; Sat, 17 Aug 2013 22:58:53 -0700 (PDT) In-Reply-To: <520FFD18.2010008@gondrom.org> References: <20130815014121.17800.33179.idtracker@ietfa.amsl.com> <520FFD18.2010008@gondrom.org> Date: Sun, 18 Aug 2013 01:58:53 -0400 X-Google-Sender-Auth: hmJe1fxZQxZgcIXS8whHmWeQttw Message-ID: From: Barry Leiba To: Tobias Gondrom Content-Type: multipart/alternative; boundary=047d7b5d533abe414104e432849d Cc: "draft-ietf-websec-x-frame-options@tools.ietf.org" , "websec@ietf.org" , "iesg@ietf.org" , "websec-chairs@tools.ietf.org" Subject: Re: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 18 Aug 2013 05:58:57 -0000 --047d7b5d533abe414104e432849d Content-Type: text/plain; charset=ISO-8859-1 > > > (D2) It seems like this is a value that browsers might cache, to avoid > > unnecessary requests if the same page is framed in the future. If this > > is something browsers do today, please say so. > > Actually I like to push back in this case, as I don't think we should go > into implementation specific details that have no effect on the bits on > the wire nor on the effective behavior of the browser. > The X-Frame-Options header determines the behaviour for every individual > requested page regarding framing in another web page in the browser. > Whether the browser caches this information and compares the request > with an existing cache from a request from before AND if the value is > identical proceeds as before or whether the browser evaluates the > X-Frame-Options header on each request should not be specified in this > draft. I'll note also that this is particularly the case because this is documenting something that exists, but that isn't recommended for implementation. If this were a PS that we were recommending for new implementations, it might make more sense to talk about how to do caching for better implementations. Barry --047d7b5d533abe414104e432849d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> (D2) It seems like this is a value that= browsers might cache, to avoid
> unnecessary requests if the same page is framed in the future. =A0If t= his
> is something browsers do today, please say so.

Actually I like to push back in this case, as I don't think we should g= o
into implementation specific details that have no effect on the bits on
the wire nor on the effective behavior of the browser.
The X-Frame-Options header determines the behaviour for every individual requested page regarding framing in another web page in the browser.
Whether the browser caches this information and compares the request
with an existing cache from a request from before AND if the value is
identical proceeds as before or whether the browser evaluates the
X-Frame-Options header on each request should not be specified in this
draft.

=A0I'll note also that this is p= articularly the case because this is documenting something that exists, but= that isn't recommended for implementation. =A0If this were a PS that w= e were recommending for new implementations, it might make more sense to ta= lk about how to do caching for better implementations.

Barry
--047d7b5d533abe414104e432849d-- From ynir@checkpoint.com Sun Aug 18 08:09:42 2013 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 0D53911E8125; Sun, 18 Aug 2013 08:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.557 X-Spam-Level: X-Spam-Status: No, score=-10.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oij7oQH2eApm; Sun, 18 Aug 2013 08:09:36 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id CBC5511E8124; Sun, 18 Aug 2013 08:09:35 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7IF9FIW015573; Sun, 18 Aug 2013 18:09:16 +0300 X-CheckPoint: {5210E39B-14-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Sun, 18 Aug 2013 18:09:14 +0300 From: Yoav Nir To: Sean Turner Thread-Topic: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) Thread-Index: AQHOmQlsFXmWJxTQ/kGarKEYKdLs8pma5XOA Date: Sun, 18 Aug 2013 15:09:14 +0000 Message-ID: References: <20130814161444.6218.82572.idtracker@ietfa.amsl.com> In-Reply-To: <20130814161444.6218.82572.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.83] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11fba70b736665cbac9b37499c89475d4a6803f027 Content-Type: text/plain; charset="us-ascii" Content-ID: <5392B4D554CD8D4FA9D126915475616F@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , The IESG , "" Subject: Re: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 18 Aug 2013 15:09:42 -0000 On Aug 14, 2013, at 7:14 PM, Sean Turner wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > It's interesting to note that this draft says there's a problem with > folks not checking the origins of the entire ancestor tree of names of > the framing resource - but then doesn't say that sounds like a good idea > do it. I can see the argument that might be made that this draft is just > documenting what's done now, but shouldn't we take the opportunity to do > more and recommend something along the lines of "The entire ancestor tree > of names of the framing resource SHOULD be checked to mitigate the risk > of attacks in multiple-nested scenarios" or something like that? Hi Sean. The text has changed in version -10. There are still no RFC 2119 w= ords there and no recommendations to browser vendors (as we take those to b= e immovable objects (the implementation, not the vendors)), but the recomme= ndations to web developers have been changed from "should be aware" to "sho= uld make sure". Since we are documenting a given situation, which we hope w= ill be changed by the CSP work, and since web developers cannot ignore the = status quo (when *is* a good time to stop targetting IE8?), does this text = change satisfy you? OLD: For example, if a resource on origin A embeds untrusted content from origin B, that untrusted content can embed another resource from origin A with an X-Frame-Options: SAMEORIGIN policy and that check would pass if the user agent only verifies the top-level browsing context. Therefore web developers should be aware that embedding content from other sites can leave their web pages vulnerable to clickjacking even if the X-Frame-Options header is used. NEW: a. If the browser implementation evaluates based on the origins of=09 the framed page and the framing page:=09 Suppose a web page A (from origin 1) embeds a web page B (from=09 origin 2) in a frame or iframe which in turn embeds web page C=09 (from origin 2) using the x-frame-options header in a frame. In=09 this case web page B needs to use X-Frame-Options as well, or=09 else a malicious page A could frame page B and with that=09 indirectly also page C. Therefore web developers should make=09 sure that all pages from an origin that is allowed to frame a=09 given resource web page C should also use X-Frame-Options or=09 otherwise risk exposing web page C indirectly to Clickjacking=09 attacks. And so forth recursively until the top-level browsing-=09 context (i.e. most outer frame) is reached.=09 =09 b. If the browser implementation evaluates based on the origin of=09 the framed page and the top-level browsing-context (i.e. most=09 outer frame):=09 If a resource from origin A embeds untrusted content from origin=09 B, that untrusted content can embed another resource from origin=09 A with an X-Frame-Options: SAMEORIGIN policy and that check would=09 pass if the user agent only verifies the top-level browsing=09 context. Therefore web developers should be aware that embedding=09 content from other sites can leave their web pages vulnerable to=09 clickjacking even if the X-Frame-Options header is used. Yoav From ynir@checkpoint.com Sun Aug 18 12:40:21 2013 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 1A1A411E8169; Sun, 18 Aug 2013 12:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.563 X-Spam-Level: X-Spam-Status: No, score=-10.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ll1sYL6wcn0F; Sun, 18 Aug 2013 12:40:15 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D45D911E811F; Sun, 18 Aug 2013 12:40:14 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7IJeCa7025291; Sun, 18 Aug 2013 22:40:12 +0300 X-CheckPoint: {5211231C-14-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Sun, 18 Aug 2013 22:40:11 +0300 From: Yoav Nir To: Richard Barnes Thread-Topic: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) Thread-Index: AQHOmViW1PGmiLYYbkq+EYlkkkwLXpmbMImA Date: Sun, 18 Aug 2013 19:40:11 +0000 Message-ID: <3BD7F636-F3DA-4204-AC23-68F868FFD4D7@checkpoint.com> References: <20130815014121.17800.33179.idtracker@ietfa.amsl.com> In-Reply-To: <20130815014121.17800.33179.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.83] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 1170fca780dc57c889946b24fb4d53df9d99ece634 Content-Type: text/plain; charset="us-ascii" Content-ID: <0028F4E458601F49889C93F4142C3B9D@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , The IESG , "" Subject: Re: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 18 Aug 2013 19:40:21 -0000 Hi Richard. Please see below. Do the changes address your concerns? Yoav On Aug 15, 2013, at 4:41 AM, Richard Barnes wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > (D1) The privacy considerations make no sense to me. To whom is data > being leaked? To the browser? To random people who send a request to a > URI? Do you mean that X-Frame-Options leaks information about who the > site authorizes? That's true, but also true of things like CORS. If > this is the concern, you should recommend a mitigation that's basically > the same as what CORS does, namely varying the value of X-Frame-Options > based on the Referer or Origin header. The text for Privacy Considerations has changed OLD: The parameter ALLOW-FROM allows a page to guess who is framing it. This is inherent by design, but may lead to data leakage or data protection concerns. NEW: There are two kinds of potential data leakage to consider: 1. Using X-FRAME-OPTIONS with the parameter ALLOW-FROM allows a page to guess or infer information about who is framing it. A web server may answer requests with the X-FRAME-OPTIONS ALLOW-FROM header and by thus determine which other page is framing it. This is inherent by design, but may lead to data leakage or data protection concerns. 2. The web server using the ALLOW-FROM directive may disclose to other parties who request the page in the header by which page it is allowed to be framed. If a web server wishes to reduce this leakage, it is recommended to generate the ALLOW-FRAM header for each request based on the design pattern as described in section 2.3.2.3. > (D2) It seems like this is a value that browsers might cache, to avoid > unnecessary requests if the same page is framed in the future. If this > is something browsers do today, please say so. =20 Since Tobias is arguing this ( ), I'll leave this one alone for now, but p= lease let us know if you've been convinced. > (D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI? In other > words, what does it mean to send "X-Frame-Options: ALLOW-FROM > https://example.com/this/is/a/path?query#fragment"? =20 OLD: ALLOW-FROM (followed by a URI [RFC3986] of a trusted origin) NEW: ALLOW-FROM (followed by a serialized-origin [RFC6454]) > (D3) In the ALLOW-FROM: what does "top level context" mean? Do you > really mean the top level here, as opposed to the next one up? For > example, suppose A loads B in an iframe, and B loads C, and then C sends > an X-Frame-Options header with ALLOW-FROM. Is the ALLOW-FROM origin > compared to B or A? In either case, you should also note the attacks > that remain. For example, if the answer is B, then B needs to use > X-Frame-Options as well, or else, A can maliciously frame A within B. Or > if the answer is A, then C is trusting A not to load any malicious > intermediate frames B. New (in sectin 2.3.2.2): To illustrate the difference between the comparison with "framing page" and the "top-level browsing-context" consider the following scenario: Web pages may embed frames with other pages which in turn embed frames with other pages as well and so on. In theory this can result in an infinite nesting of framed pages. For example web page A may contain in a frame web page B, and web page B contains in a frame web page C. Web page A .... Web Page B .... And so forth... In this example, for the nested frames with the inner framed web page C, the most outer web page A would be the "top-level browsing- context" and web page B would be the "framing page" From rlb@ipv.sx Mon Aug 19 06:38:34 2013 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 4846511E8277 for ; Mon, 19 Aug 2013 06:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.784 X-Spam-Level: X-Spam-Status: No, score=-2.784 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDSlAbTQpWZx for ; Mon, 19 Aug 2013 06:38:20 -0700 (PDT) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by ietfa.amsl.com (Postfix) with ESMTP id 36C3A11E8102 for ; Mon, 19 Aug 2013 06:38:18 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id f8so580832obp.8 for ; Mon, 19 Aug 2013 06:38:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1p3ogPlvNw52t1BfMWpwgQpHTQPG8BfiQX+ZGiBnXeU=; b=Cv+UVDPc1Jr9187Aez1n05b1qo31CzCZ2zkSX74BDIl7OpXdwlQ7ZIIfNKIEe2qyOP hN/L+EA5Dar/2qKsepjjKE3DwO2M9FX9FeYeph5tieZ1FPpM1GycvVsaKdm8cjRlafqY /pFjJ98NGa35aTKDBEMNTl4dkRElLEElw0EYXAnCqX1KSDPetA9rK2BE3iR/QkFpVBUw h1AkkwJycqZ+gXK0+o8r9I1of7cWSW6rYffvP9C1SBCif++kK2klA369fVT1w83AYZGb 0KiGZD7PNVVnv+oDS0LvBlmXlB6H0SoKLN3qJYzDKhOG2QCQGiqnw5Oihlp6HCaE1gWl 5atg== X-Gm-Message-State: ALoCoQmKJT9KmV4yBbYhaSU2H9Bh/NF5tO/638vXP9/R/1XFiJocabkXacivbeMTSPrUJqbUMT7s MIME-Version: 1.0 X-Received: by 10.60.115.164 with SMTP id jp4mr13044763oeb.19.1376919496689; Mon, 19 Aug 2013 06:38:16 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Mon, 19 Aug 2013 06:38:16 -0700 (PDT) X-Originating-IP: [192.1.255.218] In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E27BAD2A7@DEN-EXDDA-S12.corp.ebay.com> References: <20130815014121.17800.33179.idtracker@ietfa.amsl.com> <370C9BEB4DD6154FA963E2F79ADC6F2E27BAD2A7@DEN-EXDDA-S12.corp.ebay.com> Date: Mon, 19 Aug 2013 09:38:16 -0400 Message-ID: From: Richard Barnes To: "Hill, Brad" Content-Type: multipart/alternative; boundary=089e01161b467c181b04e44d0d5b Cc: "draft-ietf-websec-x-frame-options@tools.ietf.org" , "websec@ietf.org" , The IESG , "websec-chairs@tools.ietf.org" Subject: Re: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 19 Aug 2013 13:38:34 -0000 --089e01161b467c181b04e44d0d5b Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 16, 2013 at 7:44 PM, Hill, Brad wrote: > Additional comments inline. > ________________________________________ > > > (D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI? In other > words, what does it mean to send "X-Frame-Options: ALLOW-FROM > https://example.com/this/is/a/path?query#fragment"? > > [Hill, Brad] Agreed. Great. > (D3) In the ALLOW-FROM: what does "top level context" mean? Do you > really mean the top level here, as opposed to the next one up? For > example, suppose A loads B in an iframe, and B loads C, and then C sends > an X-Frame-Options header with ALLOW-FROM. Is the ALLOW-FROM origin > compared to B or A? In either case, you should also note the attacks > that remain. For example, if the answer is B, then B needs to use > X-Frame-Options as well, or else, A can maliciously frame A within B. Or > if the answer is A, then C is trusting A not to load any malicious > intermediate frames B. > > [Hill, Brad] This really does mean the top/final origin value in a frame > ancestor > chain walk. Browsers have implemented X-Frame-Options to check the > Origin context that is topmost in the window or tab. (the _top target, > representing the full, original browsing context, not just the immediate > parent frame) This could be clarified perhaps, but is not incorrect. > OK, that's fine. Could you please just note the risk that an intermediate frame in a nested scenario could do bad things? For example, in the Security Considerations: """ When SAMEORIGIN or ALLOW-FROM values are used, there is some residual risk in nested framing scenarios. For example, suppose that A loads B in an iframe; B loads C; and C sends an X-Frame-Options header with the value "ALLOW-FROM A". The browser will allow this setup, because the ALLOW-FROM origin sent by C matches the top-level origin. However, the intermediate framing page B may still be able to perform clickjacking attacks against A. Thus, sites using this mechanism should keep in mind that by emitting an X-Frame-Options header with value SAMEORIGIN or ALLOW-FROM, they are not only granting permission to the indicated origin (the same origin, or the ALLOW-FROM origin), but also to any origins included as frames within that origin. """ Thanks, --Richard --089e01161b467c181b04e44d0d5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Aug 16, 2013 at 7:44 PM, Hill, Brad <<= a href=3D"mailto:bhill@paypal-inc.com" target=3D"_blank">bhill@paypal-inc.c= om> wrote:
Additional comments inline.
________________________________________


(D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI? =A0In ot= her
words, what does it mean to send "X-Frame-Options: ALLOW-FROM
https://example.com/this/is/a/path?query#fragment"?

[Hill, Brad] Agreed.

Great.

=A0
(D3) In the ALLOW-FROM: what does "top level context" mean? =A0Do= you
really mean the top level here, as opposed to the next one up? =A0For
example, suppose A loads B in an iframe, and B loads C, and then C sends an X-Frame-Options header with ALLOW-FROM. =A0Is the ALLOW-FROM origin
compared to B or A? =A0In either case, you should also note the attacks
that remain. =A0For example, if the answer is B, then B needs to use
X-Frame-Options as well, or else, A can maliciously frame A within B. =A0Or=
if the answer is A, then C is trusting A not to load any malicious
intermediate frames B.

[Hill, Brad] =A0This really does mean the top/final origin value in a= frame ancestor
chain walk. =A0Browsers have implemented X-Frame-Options to check the
Origin context that is topmost in the window or tab. =A0(the _top target, representing the full, original browsing context, not just the immediate parent frame) =A0This could be clarified perhaps, but is not incorrect.
=

OK, that's fine. =A0Could you please j= ust note the risk that an intermediate frame in a nested scenario could do = bad things? =A0For example, in the Security Considerations:
"""
When SAMEORIGIN or ALLOW-FROM values are = used, there is some residual risk in nested framing scenarios. =A0For examp= le, suppose that A loads B in an iframe; B loads C; and C sends an X-Frame-= Options header with the value "ALLOW-FROM A". =A0The browser will= allow this setup, because the ALLOW-FROM origin sent by C matches the top-= level origin. =A0However, the intermediate framing page B may still be able= to perform clickjacking attacks against A. =A0Thus, sites using this mecha= nism should keep in mind that by emitting an X-Frame-Options header with va= lue SAMEORIGIN or ALLOW-FROM, they are not only granting permission to the = indicated origin (the same origin, or the ALLOW-FROM origin), but also to a= ny origins included as frames within that origin.
"""

Thanks,
--Richar= d



--089e01161b467c181b04e44d0d5b-- From rlb@ipv.sx Mon Aug 19 06:45:49 2013 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 79D3221F8C66 for ; Mon, 19 Aug 2013 06:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHLtQ6cU82oA for ; Mon, 19 Aug 2013 06:45:44 -0700 (PDT) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1C011E827C for ; Mon, 19 Aug 2013 06:45:44 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id wc20so5402860obb.14 for ; Mon, 19 Aug 2013 06:45:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=17sAyHyV7OPGRCzlPXRvmCenhKBXKqo+cyhtsB2vsos=; b=exAqd3teUyqdt/QwMa7ZvxUyl7MDVmbByjm4+Ss+Tekz40NC0ENdfWxPunXvhaJX/Y kU1kVA4KaRQFdIWLIdU+sSs3RE/DC++VkAvpORWggOE/vFDa4ou8iVnReVxkB/TXPnLW rqVbNAGZD3d06e/5fiA1i32TReOjRpeLxvoSelshRRF1j/FzFk/nLcXhP1/I5OsW1x4T H/wpB6mF4u0un34gZniHYRfgNe9XW5fud7EToC67ylmwMyrB65dAPSLFLbEcT7y1gcul jwGppMKgluBoVhRq7ca0QOZuoVlUQQot5lazrqLb7BfheggbKae4roI5Gy5nOEVydtZn QRoQ== X-Gm-Message-State: ALoCoQmyE6VvRarKLr+lEacu8vrHYFDB/uaB/FlR36VQpu4BZJEnWAtgOWN6VN9XUAV18DeEokHI MIME-Version: 1.0 X-Received: by 10.182.104.130 with SMTP id ge2mr13123793obb.6.1376919944120; Mon, 19 Aug 2013 06:45:44 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Mon, 19 Aug 2013 06:45:44 -0700 (PDT) X-Originating-IP: [192.1.255.218] In-Reply-To: <520FFD18.2010008@gondrom.org> References: <20130815014121.17800.33179.idtracker@ietfa.amsl.com> <520FFD18.2010008@gondrom.org> Date: Mon, 19 Aug 2013 09:45:44 -0400 Message-ID: From: Richard Barnes To: Tobias Gondrom Content-Type: multipart/alternative; boundary=089e0112cf10275ae304e44d2806 Cc: "draft-ietf-websec-x-frame-options@tools.ietf.org" , websec , The IESG , "websec-chairs@tools.ietf.org" Subject: Re: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 19 Aug 2013 13:45:49 -0000 --089e0112cf10275ae304e44d2806 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Aug 17, 2013 at 6:45 PM, Tobias Gondrom wrote: > Dear Richard, > > thanks for the review and your discusses and comments. > Answers inline. > I followed all your suggestions in version-10, except for D2. > Thanks for the review and all the best, > > Tobias > > > > On 15/08/13 02:41, Richard Barnes wrote: > > Richard Barnes has entered the following ballot position for > > draft-ietf-websec-x-frame-options-09: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > (D1) The privacy considerations make no sense to me. To whom is data > > being leaked? To the browser? To random people who send a request to a > > URI? Do you mean that X-Frame-Options leaks information about who the > > site authorizes? That's true, but also true of things like CORS. If > > this is the concern, you should recommend a mitigation that's basically > > the same as what CORS does, namely varying the value of X-Frame-Options > > based on the Referer or Origin header. > Yes. > Ok. I expanded the text and explanation of the privacy considerations > section accordingly. > > > > > (D2) It seems like this is a value that browsers might cache, to avoid > > unnecessary requests if the same page is framed in the future. If this > > is something browsers do today, please say so. > > Actually I like to push back in this case, as I don't think we should go > into implementation specific details that have no effect on the bits on > the wire nor on the effective behavior of the browser. > The X-Frame-Options header determines the behaviour for every individual > requested page regarding framing in another web page in the browser. > Whether the browser caches this information and compares the request > with an existing cache from a request from before AND if the value is > identical proceeds as before or whether the browser evaluates the > X-Frame-Options header on each request should not be specified in this > draft. > > I get this. I'm actually just asking for some clarification about what browsers do -- whether they do or don't cache X-Frame-Options settings. It seems like something that could cause problems for web site operators, so it would be helpful to know. Not looking for any normative text here. > > > > (D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI? In other > > words, what does it mean to send "X-Frame-Options: ALLOW-FROM > > https://example.com/this/is/a/path?query#fragment"? > > Yes. You are right we can refine the definition to "serialized-origin" > (as a subset of URI). > Please note that according to RFC6454 we need to use "serialized-origin" > here and not origin (as origin in RFC6454 refers also to a list of > origins, which would not be acceptable here). > I adjusted the text accordingly. > > Note: From an editorial standpoint we can debate whether to use lower > case "serialized-origin" or capital "SERIALIZED-ORIGIN". RFC6454 uses > lower case. So I used that one, but I am open for either. It seems like the ABNF in this document should just import the ABNF from RF 6454. So, "serialized-origin". > > > > > (D3) In the ALLOW-FROM: what does "top level context" mean? Do you > > really mean the top level here, as opposed to the next one up? > Yes. And unfortunately with the problems you outlined in the next > sentence (which are also described in the security considerations > sections of the draft.) > Ted raised a related comment. So I guess the current text regarding > nesting and potential problem is not sufficiently clear. So I will add > further explanations. And I will add a reference to the security > considerations section which already contains a paragraph about this > problem. (i.e. the 2nd paragraph). > > > > For > > example, suppose A loads B in an iframe, and B loads C, and then C sends > > an X-Frame-Options header with ALLOW-FROM. Is the ALLOW-FROM origin > > compared to B or A? In either case, you should also note the attacks > > that remain. For example, if the answer is B, then B needs to use > > X-Frame-Options as well, or else, A can maliciously frame A within B. Or > > if the answer is A, then C is trusting A not to load any malicious > > intermediate frames B. > I added text accordingly to section 5. > (and I initiated a research query to re-confirm again that we still have > the two inconsistent browser behaviour cases here (framing page vs. > top-level frame, as I wrote in the draft). Great, that should be fine. I've gone ahead and cleared this point. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > (C1) In the Introduction, the phrase "secure web page" would seem to > > imply that this mechanism only applies to pages delivered over HTTPS, > > which I'm pretty sure isn't true. Suggest just deleting "secure". > Ok. removed. > > > > > (C2) In Section 2.1, the sentence starting "And the algorithm" seems to > > imply that ALLOW-FROM allows SAMEORIGIN requests as well, which I think > > you actually mean something like: > > """ > > And the algorithm to compare origins from [RFC6454] SHOULD be used to > > verify that a referring page is of the same origin as the content (in the > > case of SAMEORIGIN) or that the referring page's origin is identical with > > the ALLOW-FROM URI (in the case of ALLOW-FROM). > > """ > Thank you. I changed the text to your suggestion. > > > > > _______________________________________________ > > websec mailing list > > websec@ietf.org > > https://www.ietf.org/mailman/listinfo/websec > > --089e0112cf10275ae304e44d2806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Aug 17, 2013 at 6:45 PM, Tobias Gondrom &= lt;tobias.g= ondrom@gondrom.org> wrote:
Dear Richard,

thanks for the review and your discusses and comments.
Answers inline.
I followed all your suggestions in version-10, except for D2.
Thanks for the review and all the best,

Tobias



On 15/08/13 02:41, Richard Barnes wrote:
> Richard Barnes has entered the following ballot position for
> draft-ietf-websec-x-frame-options-09: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss= -criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-webse= c-x-frame-options/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> (D1) The privacy considerations make no sense to me. =A0To whom is dat= a
> being leaked? =A0To the browser? =A0To random people who send a reques= t to a
> URI? =A0Do you mean that X-Frame-Options leaks information about who t= he
> site authorizes? =A0That's true, but also true of things like CORS= . =A0If
> this is the concern, you should recommend a mitigation that's basi= cally
> the same as what CORS does, namely varying the value of X-Frame-Option= s
> based on the Referer or Origin header.
Yes.
Ok. I expanded the text and explanation of the privacy considerations
section accordingly.

>
> (D2) It seems like this is a value that browsers might cache, to avoid=
> unnecessary requests if the same page is framed in the future. =A0If t= his
> is something browsers do today, please say so.

Actually I like to push back in this case, as I don't think we sh= ould go
into implementation specific details that have no effect on the bits on
the wire nor on the effective behavior of the browser.
The X-Frame-Options header determines the behaviour for every individual requested page regarding framing in another web page in the browser.
Whether the browser caches this information and compares the request
with an existing cache from a request from before AND if the value is
identical proceeds as before or whether the browser evaluates the
X-Frame-Options header on each request should not be specified in this
draft.



I get this. =A0I'm actually just asking for some clarification about w= hat browsers do -- whether they do or don't cache X-Frame-Options setti= ngs. =A0It seems like something that could cause problems for web site oper= ators, so it would be helpful to know. =A0Not looking for any normative tex= t here.

=A0
>
> (D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI? =A0= In other
> words, what does it mean to send "X-Frame-Options: ALLOW-FROM
> https://example.com/this/is/a/path?query#fragment"?
Yes. You are right we can refine the definition to "serialized-o= rigin"
(as a subset of URI).
Please note that according to RFC6454 we need to use "serialized-origi= n"
here and not origin (as origin in RFC6454 refers also to a list of
origins, which would not be acceptable here).
I adjusted the text accordingly.

Note: From an editorial standpoint we can debate whether to use lower
case "serialized-origin" or capital "SERIALIZED-ORIGIN"= . RFC6454 uses
lower case. So I used that one, but I am open for either.
=

It seems like the ABNF in this document shoul= d just import the ABNF from RF 6454. =A0So, "serialized-origin".<= /div>

=A0

>
> (D3) In the ALLOW-FROM: what does "top level context" mean? = =A0Do you
> really mean the top level here, as opposed to the next one up?
Yes. And unfortunately with the problems you outlined in the next
sentence (which are also described in the security considerations
sections of the draft.)
Ted raised a related comment. So I guess the current text regarding
nesting and potential problem is not sufficiently clear. So I will add
further explanations. And I will add a reference to the security
considerations section which already contains a paragraph about this
problem. (i.e. the 2nd paragraph).


> For
> example, suppose A loads B in an iframe, and B loads C, and then C sen= ds
> an X-Frame-Options header with ALLOW-FROM. =A0Is the ALLOW-FROM origin=
> compared to B or A? =A0In either case, you should also note the attack= s
> that remain. =A0For example, if the answer is B, then B needs to use > X-Frame-Options as well, or else, A can maliciously frame A within B. = =A0Or
> if the answer is A, then C is trusting A not to load any malicious
> intermediate frames B.
I added text accordingly to section 5.
(and I initiated a research query to re-confirm again that we still have the two inconsistent browser behaviour cases here (framing page vs.
top-level frame, as I wrote in the draft).

= Great, that should be fine. =A0I've gone ahead and cleared this point.= =A0


=A0
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> (C1) In the Introduction, the phrase "secure web page" would= seem to
> imply that this mechanism only applies to pages delivered over HTTPS,<= br> > which I'm pretty sure isn't true. =A0Suggest just deleting &qu= ot;secure".
Ok. removed.

>
> (C2) In Section 2.1, the sentence starting "And the algorithm&quo= t; seems to
> imply that ALLOW-FROM allows SAMEORIGIN requests as well, which I thin= k
> you actually mean something like:
> """
> And the algorithm to compare origins from [RFC6454] SHOULD be used to<= br> > verify that a referring page is of the same origin as the content (in = the
> case of SAMEORIGIN) or that the referring page's origin is identic= al with
> the ALLOW-FROM URI (in the case of ALLOW-FROM).
> """
Thank you. I changed the text to your suggestion.

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


--089e0112cf10275ae304e44d2806-- From rlb@ipv.sx Mon Aug 19 06:46:46 2013 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 2C71B11E827E for ; Mon, 19 Aug 2013 06:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMEocFJLj5Tv for ; Mon, 19 Aug 2013 06:46:40 -0700 (PDT) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id 35C6B11E8115 for ; Mon, 19 Aug 2013 06:46:40 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wo10so5438774obc.13 for ; Mon, 19 Aug 2013 06:46:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hJYTEaNe3Ff3v/UfLJt9qupg+PmrnxYvKwiGQ8hC2m0=; b=HbgHYnSgJrE78HDD3daEQ774ga5EuMDDyq9cgnApBxg1EoxwCvyZnn80tLsX4pt7Gi PU9N03OuLnMJTY9oXzTgIFbF9aE4XGNySM8Covo5CAh0cjw+0NQUKRlN6X+/ljF6F2T6 Fz92UHK+uQ9+qMruQyKDyU125nOZ/zCM22UsjYRiEDPvTQEEgK5ZOOWS6rKI5X76WQbQ IH5XiFm2lHNKVOLzXwHEra/OIEOOSS+HxmOW5ssUs5R+S0CR+rOARK3jglvnVecYIvza owwsQCHX3qz2a3dZXDLdLQ+zcVyiq+jENleFgZ2o8Mu/mG+o998vOo0wtRilDSG8T4U4 R3Pg== X-Gm-Message-State: ALoCoQkc2NlqyzBpoweNjpm8XPf35s0iVknC/wnhx1aDxjX5gxkCX+WCuPpeCLF8lbqPlzwVbX4F MIME-Version: 1.0 X-Received: by 10.182.18.9 with SMTP id s9mr13367783obd.15.1376919999720; Mon, 19 Aug 2013 06:46:39 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Mon, 19 Aug 2013 06:46:39 -0700 (PDT) X-Originating-IP: [192.1.255.218] In-Reply-To: References: <20130815014121.17800.33179.idtracker@ietfa.amsl.com> <370C9BEB4DD6154FA963E2F79ADC6F2E27BAD2A7@DEN-EXDDA-S12.corp.ebay.com> Date: Mon, 19 Aug 2013 09:46:39 -0400 Message-ID: From: Richard Barnes To: "Hill, Brad" Content-Type: multipart/alternative; boundary=001a11c2d6a077c19904e44d2b69 Cc: "draft-ietf-websec-x-frame-options@tools.ietf.org" , "websec@ietf.org" , The IESG , "websec-chairs@tools.ietf.org" Subject: Re: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 19 Aug 2013 13:46:46 -0000 --001a11c2d6a077c19904e44d2b69 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 19, 2013 at 9:38 AM, Richard Barnes wrote: > > > > On Fri, Aug 16, 2013 at 7:44 PM, Hill, Brad wrote: > >> Additional comments inline. >> ________________________________________ >> >> >> (D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI? In other >> words, what does it mean to send "X-Frame-Options: ALLOW-FROM >> https://example.com/this/is/a/path?query#fragment"? >> >> [Hill, Brad] Agreed. > > > Great. > > > >> (D3) In the ALLOW-FROM: what does "top level context" mean? Do you >> really mean the top level here, as opposed to the next one up? For >> example, suppose A loads B in an iframe, and B loads C, and then C sends >> an X-Frame-Options header with ALLOW-FROM. Is the ALLOW-FROM origin >> compared to B or A? In either case, you should also note the attacks >> that remain. For example, if the answer is B, then B needs to use >> X-Frame-Options as well, or else, A can maliciously frame A within B. Or >> if the answer is A, then C is trusting A not to load any malicious >> intermediate frames B. >> >> [Hill, Brad] This really does mean the top/final origin value in a frame >> ancestor >> chain walk. Browsers have implemented X-Frame-Options to check the >> Origin context that is topmost in the window or tab. (the _top target, >> representing the full, original browsing context, not just the immediate >> parent frame) This could be clarified perhaps, but is not incorrect. >> > > OK, that's fine. Could you please just note the risk that an intermediate > frame in a nested scenario could do bad things? For example, in the > Security Considerations: > """ > When SAMEORIGIN or ALLOW-FROM values are used, there is some residual risk > in nested framing scenarios. For example, suppose that A loads B in an > iframe; B loads C; and C sends an X-Frame-Options header with the value > "ALLOW-FROM A". The browser will allow this setup, because the ALLOW-FROM > origin sent by C matches the top-level origin. However, the intermediate > framing page B may still be able to perform clickjacking attacks against A. > Thus, sites using this mechanism should keep in mind that by emitting an > X-Frame-Options header with value SAMEORIGIN or ALLOW-FROM, they are not > only granting permission to the indicated origin (the same origin, or the > ALLOW-FROM origin), but also to any origins included as frames within that > origin. > """ > Update: Feel free to ignore this suggestion (or steal text if you think it's helpful). I think Tobias is on the right track with what he suggested. That's what I get for responding to email in chronological order :) --Ricahrd > > Thanks, > --Richard > > > > --001a11c2d6a077c19904e44d2b69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Aug 19, 2013 at 9:38 AM, Richard Barnes &= lt;rlb@ipv.sx> wrote:



On Fri, Aug 16, 20= 13 at 7:44 PM, Hill, Brad <bhill@paypal-inc.com> wrote:
Additional comments inline.
________________________________________


(D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI? =A0In ot= her
words, what does it mean to send "X-Frame-Options: ALLOW-FROM
https://example.com/this/is/a/path?query#fragment"?

[Hill, Brad] Agreed.

Great.

=A0
(D3) In the ALLOW-FROM: what does "top level context" mean? =A0Do= you
really mean the top level here, as opposed to the next one up? =A0For
example, suppose A loads B in an iframe, and B loads C, and then C sends an X-Frame-Options header with ALLOW-FROM. =A0Is the ALLOW-FROM origin
compared to B or A? =A0In either case, you should also note the attacks
that remain. =A0For example, if the answer is B, then B needs to use
X-Frame-Options as well, or else, A can maliciously frame A within B. =A0Or=
if the answer is A, then C is trusting A not to load any malicious
intermediate frames B.

[Hill, Brad] =A0This really does mean the top/final origin value in a= frame ancestor
chain walk. =A0Browsers have implemented X-Frame-Options to check the
Origin context that is topmost in the window or tab. =A0(the _top target, representing the full, original browsing context, not just the immediate parent frame) =A0This could be clarified perhaps, but is not incorrect.
=

OK, that's fine. =A0Could you pl= ease just note the risk that an intermediate frame in a nested scenario cou= ld do bad things? =A0For example, in the Security Considerations:
"""
When SAMEORIGIN or ALLOW-FROM values are = used, there is some residual risk in nested framing scenarios. =A0For examp= le, suppose that A loads B in an iframe; B loads C; and C sends an X-Frame-= Options header with the value "ALLOW-FROM A". =A0The browser will= allow this setup, because the ALLOW-FROM origin sent by C matches the top-= level origin. =A0However, the intermediate framing page B may still be able= to perform clickjacking attacks against A. =A0Thus, sites using this mecha= nism should keep in mind that by emitting an X-Frame-Options header with va= lue SAMEORIGIN or ALLOW-FROM, they are not only granting permission to the = indicated origin (the same origin, or the ALLOW-FROM origin), but also to a= ny origins included as frames within that origin.
"""

=
Update: Feel free to ignore this suggestion (or steal text if you thin= k it's helpful). =A0I think Tobias is on the right track with what he s= uggested. =A0That's what I get for responding to email in chronological= order :)

--Ricahrd


=A0

Thanks,
--Richard



--001a11c2d6a077c19904e44d2b69-- From rlb@ipv.sx Mon Aug 19 06:48:48 2013 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 AE6AE11E8286 for ; Mon, 19 Aug 2013 06:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.845 X-Spam-Level: X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OG+0VG2vPgWc for ; Mon, 19 Aug 2013 06:48:42 -0700 (PDT) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by ietfa.amsl.com (Postfix) with ESMTP id C9DEE11E8283 for ; Mon, 19 Aug 2013 06:48:40 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id tb18so5409691obb.16 for ; Mon, 19 Aug 2013 06:48:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gAPCdRK4reUyMigkNjMf39HRmBKtn9Yz7nY/gCykDAw=; b=nhsdvA/Li6Hz5hPCLZ6jNNV/qF9sL9TiwNQ2F/uoUcPRpG7qlKhExDY5D+nqt0qVWq xb2h4WApQk7KBTz8ImaNryEkQt9St8oOOx9itrcUfoWYRfu03v3/7zLRkAbdHpgmlRCx QZKjd6yYvT5aDMB1x1UbUTUgnOtuQTH7W2slkVLJIFLEURq+Pdf7qp5fa5ZBK4uYyxvK vcCpTTbsE5cgMF2k/JRyYM4e7TO7H+DuO6mS9f+Y4nJHU8bf4zL4rwVZjipXKKv/vK4x +o2aURILcwcPi/m7xHRk6McNQVFnZ20GXj7mSkJI5TgmaKTIvdLxeWul8Q/ZyB3o9srC /MRA== X-Gm-Message-State: ALoCoQm5yAXSKGRkSEe8+frB3/IEmba4E2W1awCKfbR07C15LETa8lOn798NJ+qzwkR3NO9UpEwW MIME-Version: 1.0 X-Received: by 10.60.96.169 with SMTP id dt9mr13089103oeb.27.1376920119284; Mon, 19 Aug 2013 06:48:39 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Mon, 19 Aug 2013 06:48:39 -0700 (PDT) X-Originating-IP: [192.1.255.218] In-Reply-To: References: <20130815014121.17800.33179.idtracker@ietfa.amsl.com> <520FFD18.2010008@gondrom.org> Date: Mon, 19 Aug 2013 09:48:39 -0400 Message-ID: From: Richard Barnes To: Barry Leiba Content-Type: multipart/alternative; boundary=089e0117601f98268404e44d325a Cc: "draft-ietf-websec-x-frame-options@tools.ietf.org" , "websec@ietf.org" , "iesg@ietf.org" , "websec-chairs@tools.ietf.org" Subject: Re: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 19 Aug 2013 13:48:48 -0000 --089e0117601f98268404e44d325a Content-Type: text/plain; charset=ISO-8859-1 On Sun, Aug 18, 2013 at 1:58 AM, Barry Leiba wrote: > > (D2) It seems like this is a value that browsers might cache, to avoid >> > unnecessary requests if the same page is framed in the future. If this >> > is something browsers do today, please say so. >> >> Actually I like to push back in this case, as I don't think we should go >> into implementation specific details that have no effect on the bits on >> the wire nor on the effective behavior of the browser. >> The X-Frame-Options header determines the behaviour for every individual >> requested page regarding framing in another web page in the browser. >> Whether the browser caches this information and compares the request >> with an existing cache from a request from before AND if the value is >> identical proceeds as before or whether the browser evaluates the >> X-Frame-Options header on each request should not be specified in this >> draft. > > > I'll note also that this is particularly the case because this is > documenting something that exists, but that isn't recommended for > implementation. If this were a PS that we were recommending for new > implementations, it might make more sense to talk about how to do caching > for better implementations. > > Barry > I understand. Caching is just another aspect of existing implementation behavior that I think should be documented. Of course, I may be off base here. If nobody does it, and people think it's patently obvious that you never would, then I could clear. --Richard --089e0117601f98268404e44d325a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Aug 18, 2013 at 1:58 AM, Barry Leiba <= barryleiba@com= puter.org> wrote:
> (D2) It seems like this is a value that browsers might cache, to = avoid
> unnecessary requests if the same page is framed in the future. =A0If t= his
> is something browsers do today, please say so.

Actually I like to push back in this case, as I don't think we should g= o
into implementation specific details that have no effect on the bits on
the wire nor on the effective behavior of the browser.
The X-Frame-Options header determines the behaviour for every individual requested page regarding framing in another web page in the browser.
Whether the browser caches this information and compares the request
with an existing cache from a request from before AND if the value is
identical proceeds as before or whether the browser evaluates the
X-Frame-Options header on each request should not be specified in this
draft.

=A0I'll note also that thi= s is particularly the case because this is documenting something that exist= s, but that isn't recommended for implementation. =A0If this were a PS = that we were recommending for new implementations, it might make more sense= to talk about how to do caching for better implementations.

Barry

I understand. =A0Caching is just another aspect of existing implementati= on behavior that I think should be documented. =A0

Of course, I may be off base here. =A0If nobody does it, and people think i= t's patently obvious that you never would, then I could clear.=A0
=

--Richard

--089e0117601f98268404e44d325a-- From tobias.gondrom@gondrom.org Mon Aug 19 07:41:56 2013 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 CFEEF21F9B0D for ; Mon, 19 Aug 2013 07:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.361 X-Spam-Level: X-Spam-Status: No, score=-95.361 tagged_above=-999 required=5 tests=[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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VW17YPVnLGhH for ; Mon, 19 Aug 2013 07:41:51 -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 D099611E8106 for ; Mon, 19 Aug 2013 07:41:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=sGQEDcdUKzk2GhljAJp5Wh2lQYVrSCe9ylN/93MkJ+Q1j9UBAEgqzkFePPJZ/aGsWE/+2wETtqrF4gq2o/oTzkK6Nk+bQMdRxMOBD55a97iv6v/r5gXId80qFnuDD42H; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 9615 invoked from network); 19 Aug 2013 16:41:49 +0200 Received: from port-83-236-131-2.static.qsc.de (HELO ?10.13.163.52?) (83.236.131.2) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Aug 2013 16:41:49 +0200 Message-ID: <52122EAD.8010503@gondrom.org> Date: Mon, 19 Aug 2013 16:41:49 +0200 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: rlb@ipv.sx References: <20130815014121.17800.33179.idtracker@ietfa.amsl.com> <520FFD18.2010008@gondrom.org> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------040507080205060407000206" Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, barryleiba@computer.org, websec@ietf.org, iesg@ietf.org, websec-chairs@tools.ietf.org Subject: Re: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 19 Aug 2013 14:41:56 -0000 This is a multi-part message in MIME format. --------------040507080205060407000206 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 19/08/13 15:48, Richard Barnes wrote: > > > > On Sun, Aug 18, 2013 at 1:58 AM, Barry Leiba > wrote: > > > (D2) It seems like this is a value that browsers might > cache, to avoid > > unnecessary requests if the same page is framed in the > future. If this > > is something browsers do today, please say so. > > Actually I like to push back in this case, as I don't think we > should go > into implementation specific details that have no effect on > the bits on > the wire nor on the effective behavior of the browser. > The X-Frame-Options header determines the behaviour for every > individual > requested page regarding framing in another web page in the > browser. > Whether the browser caches this information and compares the > request > with an existing cache from a request from before AND if the > value is > identical proceeds as before or whether the browser evaluates the > X-Frame-Options header on each request should not be specified > in this > draft. > > > I'll note also that this is particularly the case because this is > documenting something that exists, but that isn't recommended for > implementation. If this were a PS that we were recommending for > new implementations, it might make more sense to talk about how to > do caching for better implementations. > > Barry > > > I understand. Caching is just another aspect of existing > implementation behavior that I think should be documented. > > Of course, I may be off base here. If nobody does it, and people > think it's patently obvious that you never would, then I could clear. > > --Richard > Richard, in short: I think, we really don't need and in fact should not discuss caching of the existing implementations in this draft. Some info fyi: caching has only very limited (or no) benefit here. Because the browser has to check for every http-request of the resource whether the X-Frame-Options header has been set and then act accordingly. It is also a very simple check. And consider as a page itself might be dynamic, the header can change with it, too. As mentioned in my answer before the only mini advantage of caching might be that the browser sees the header is still the same as before (with a simple TRUE/FALSE regex) and then doesn't have to evaluate the ruleset again e.g. if ALLOW-FROM is set if you already did so in your previous call. But nearly all of the X-Frame-Options requests are DENY or SAMEORIGIN in which case the comparison of the header with the previous one would not be much cheaper than to just run the regex rule for the header itself. And also, as outlined in section 2.3.2.3., servers may generate X-Frame-Options header responses depending on the request. Example case: Consider that we have only one serialized-origin in the ALLOW-FROM directive. Now imagine a user has multiple pages open in his browser tabs with one of web page 1 from domain A and the second of web page 2 from domain B both frame the same page from domain C with the ALLOW-FROM directive. In that case the page needs to reply to both requests with different X-Frame-Options headers, the first pointing to origin A, the second to origin B. But then many implementations don't support the ALLOW-FROM directive.... So to summarize my answer: we really don't need and in fact should not discuss caching of the existing implementations. All the best, Tobias --------------040507080205060407000206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 19/08/13 15:48, Richard Barnes wrote:



On Sun, Aug 18, 2013 at 1:58 AM, Barry Leiba <barryleiba@computer.org> wrote:
> (D2) It seems like this is a value that browsers might cache, to avoid
> unnecessary requests if the same page is framed in the future.  If this
> is something browsers do today, please say so.

Actually I like to push back in this case, as I don't think we should go
into implementation specific details that have no effect on the bits on
the wire nor on the effective behavior of the browser.
The X-Frame-Options header determines the behaviour for every individual
requested page regarding framing in another web page in the browser.
Whether the browser caches this information and compares the request
with an existing cache from a request from before AND if the value is
identical proceeds as before or whether the browser evaluates the
X-Frame-Options header on each request should not be specified in this
draft.

 I'll note also that this is particularly the case because this is documenting something that exists, but that isn't recommended for implementation.  If this were a PS that we were recommending for new implementations, it might make more sense to talk about how to do caching for better implementations.

Barry

I understand.  Caching is just another aspect of existing implementation behavior that I think should be documented.  

Of course, I may be off base here.  If nobody does it, and people think it's patently obvious that you never would, then I could clear. 

--Richard


Richard,

in short: I think, we really don't need and in fact should not discuss caching of the existing implementations in this draft.

Some info fyi:
caching has only very limited (or no) benefit here. Because the browser has to check for every http-request of the resource whether the X-Frame-Options header has been set and then act accordingly. It is also a very simple check.

And consider as a page itself might be dynamic, the header can change with it, too.

As mentioned in my answer before the only mini advantage of caching might be that the browser sees the header is still the same as before (with a simple TRUE/FALSE regex) and then doesn't have to evaluate the ruleset again e.g. if ALLOW-FROM is set if you already did so in your previous call.
But nearly all of the X-Frame-Options requests are DENY or SAMEORIGIN in which case the comparison of the header with the previous one would not be much cheaper than to just run the regex rule for the header itself.

And also, as outlined in section 2.3.2.3., servers may generate X-Frame-Options header responses depending on the request.
Example case: Consider that we have only one serialized-origin in the ALLOW-FROM directive. Now imagine a user has multiple pages open in his browser tabs with one of web page 1 from domain A and the second of web page 2 from domain B both frame the same page from domain C with the ALLOW-FROM directive. In that case the page needs to reply to both requests with different X-Frame-Options headers, the first pointing to origin A, the second to origin B.
But then many implementations don't support the ALLOW-FROM directive....

So to summarize my answer: we really don't need and in fact should not discuss caching of the existing implementations.

All the best, Tobias





--------------040507080205060407000206-- From tobias.gondrom@gondrom.org Mon Aug 19 07:44:37 2013 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 C5C6011E8295 for ; Mon, 19 Aug 2013 07:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.361 X-Spam-Level: X-Spam-Status: No, score=-95.361 tagged_above=-999 required=5 tests=[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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwx95sQ2FQEy for ; Mon, 19 Aug 2013 07: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 56DA611E8107 for ; Mon, 19 Aug 2013 07:44:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=qiYS6B/f48mwywTk/UZTpQA3a87xkh18YkRAiCO7bPKq7ZcX64OPI4gYS5r98PF77mMJ/3jHKh0GwPUIPXNs+A5NiHCAvoeIPsZNcKtRXXc65EKz2xweacaB+easSnks; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 9704 invoked from network); 19 Aug 2013 16:44:14 +0200 Received: from port-83-236-131-2.static.qsc.de (HELO ?10.13.163.52?) (83.236.131.2) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Aug 2013 16:44:13 +0200 Message-ID: <52122F3D.4010306@gondrom.org> Date: Mon, 19 Aug 2013 16:44:13 +0200 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: rlb@ipv.sx References: <20130815014121.17800.33179.idtracker@ietfa.amsl.com> <370C9BEB4DD6154FA963E2F79ADC6F2E27BAD2A7@DEN-EXDDA-S12.corp.ebay.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------080602070809020602060503" Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, iesg@ietf.org, websec-chairs@tools.ietf.org Subject: Re: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 19 Aug 2013 14:44:37 -0000 This is a multi-part message in MIME format. --------------080602070809020602060503 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 19/08/13 15:46, Richard Barnes wrote: > > > > On Mon, Aug 19, 2013 at 9:38 AM, Richard Barnes > wrote: > > > > > On Fri, Aug 16, 2013 at 7:44 PM, Hill, Brad > wrote: > > Additional comments inline. > ________________________________________ > > > (D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI? > In other > words, what does it mean to send "X-Frame-Options: ALLOW-FROM > https://example.com/this/is/a/path?query#fragment"? > > [Hill, Brad] Agreed. > > > Great. > > > > (D3) In the ALLOW-FROM: what does "top level context" mean? > Do you > really mean the top level here, as opposed to the next one up? > For > example, suppose A loads B in an iframe, and B loads C, and > then C sends > an X-Frame-Options header with ALLOW-FROM. Is the ALLOW-FROM > origin > compared to B or A? In either case, you should also note the > attacks > that remain. For example, if the answer is B, then B needs to use > X-Frame-Options as well, or else, A can maliciously frame A > within B. Or > if the answer is A, then C is trusting A not to load any malicious > intermediate frames B. > > [Hill, Brad] This really does mean the top/final origin value > in a frame ancestor > chain walk. Browsers have implemented X-Frame-Options to > check the > Origin context that is topmost in the window or tab. (the > _top target, > representing the full, original browsing context, not just the > immediate > parent frame) This could be clarified perhaps, but is not > incorrect. > > > OK, that's fine. Could you please just note the risk that an > intermediate frame in a nested scenario could do bad things? For > example, in the Security Considerations: > """ > When SAMEORIGIN or ALLOW-FROM values are used, there is some > residual risk in nested framing scenarios. For example, suppose > that A loads B in an iframe; B loads C; and C sends an > X-Frame-Options header with the value "ALLOW-FROM A". The browser > will allow this setup, because the ALLOW-FROM origin sent by C > matches the top-level origin. However, the intermediate framing > page B may still be able to perform clickjacking attacks against > A. Thus, sites using this mechanism should keep in mind that by > emitting an X-Frame-Options header with value SAMEORIGIN or > ALLOW-FROM, they are not only granting permission to the indicated > origin (the same origin, or the ALLOW-FROM origin), but also to > any origins included as frames within that origin. > """ > > > Update: Feel free to ignore this suggestion (or steal text if you > think it's helpful). I think Tobias is on the right track with what > he suggested. That's what I get for responding to email in > chronological order :) > > --Ricahrd Dear Richard, no problem, happens to me, too. Synchronous and asynchronous processing. ;-) I will keep the new revised wording in version-10 as is. Thanks, Tobias > > > > > > Thanks, > --Richard > > > > > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec --------------080602070809020602060503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 19/08/13 15:46, Richard Barnes wrote:



On Mon, Aug 19, 2013 at 9:38 AM, Richard Barnes <rlb@ipv.sx> wrote:



On Fri, Aug 16, 2013 at 7:44 PM, Hill, Brad <bhill@paypal-inc.com> wrote:
Additional comments inline.
________________________________________


(D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI?  In other
words, what does it mean to send "X-Frame-Options: ALLOW-FROM
https://example.com/this/is/a/path?query#fragment"?

[Hill, Brad] Agreed.

Great.

 
(D3) In the ALLOW-FROM: what does "top level context" mean?  Do you
really mean the top level here, as opposed to the next one up?  For
example, suppose A loads B in an iframe, and B loads C, and then C sends
an X-Frame-Options header with ALLOW-FROM.  Is the ALLOW-FROM origin
compared to B or A?  In either case, you should also note the attacks
that remain.  For example, if the answer is B, then B needs to use
X-Frame-Options as well, or else, A can maliciously frame A within B.  Or
if the answer is A, then C is trusting A not to load any malicious
intermediate frames B.

[Hill, Brad]  This really does mean the top/final origin value in a frame ancestor
chain walk.  Browsers have implemented X-Frame-Options to check the
Origin context that is topmost in the window or tab.  (the _top target,
representing the full, original browsing context, not just the immediate
parent frame)  This could be clarified perhaps, but is not incorrect.

OK, that's fine.  Could you please just note the risk that an intermediate frame in a nested scenario could do bad things?  For example, in the Security Considerations:
"""
When SAMEORIGIN or ALLOW-FROM values are used, there is some residual risk in nested framing scenarios.  For example, suppose that A loads B in an iframe; B loads C; and C sends an X-Frame-Options header with the value "ALLOW-FROM A".  The browser will allow this setup, because the ALLOW-FROM origin sent by C matches the top-level origin.  However, the intermediate framing page B may still be able to perform clickjacking attacks against A.  Thus, sites using this mechanism should keep in mind that by emitting an X-Frame-Options header with value SAMEORIGIN or ALLOW-FROM, they are not only granting permission to the indicated origin (the same origin, or the ALLOW-FROM origin), but also to any origins included as frames within that origin.
"""

Update: Feel free to ignore this suggestion (or steal text if you think it's helpful).  I think Tobias is on the right track with what he suggested.  That's what I get for responding to email in chronological order :)

--Ricahrd

Dear Richard,
no problem, happens to me, too.
Synchronous and asynchronous processing. ;-)

I will keep the new revised wording in version-10 as is.

Thanks, Tobias




 

Thanks,
--Richard






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

--------------080602070809020602060503-- From rlb@ipv.sx Mon Aug 19 08:42:19 2013 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 CBFD321F93BF for ; Mon, 19 Aug 2013 08:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nDg0jN-daeb for ; Mon, 19 Aug 2013 08:42:14 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id A3F9E11E8259 for ; Mon, 19 Aug 2013 08:42:14 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id o6so6241825oag.41 for ; Mon, 19 Aug 2013 08:42:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HSPq66vpCUSCb9mfU0cjHwo/GhP3CRO8fNpEuBBIVnA=; b=VA0GBtcaq2zRoGJE0GkJDqQOZqQwglKTKXtcITMwBYGNFeqGgALDv/84UAxRWGvwkQ Zaqp5bO1Wmbau8Rg8PP8fWbBtPcYbhAThNdcWghT3GhI/4ShO+3IzGxXPII5BNRAme76 ndvKm9i5sOq1A93zFywaAKnUc40johQNtdHxZvC642sSts4XYjJTvKaoiocUGI4Q3t/8 fjHVHocTG1UChyWszy0jEBGH6hcJIyc12m14kzWBpDQL6qtHIrN3O6P1ayNcRorZv8yq vUEyCAT4v7UPa6GDoPTzzDyA/uu67PxTjcqOd0fQk2XPJeynzM6bh9r18Djpb3R8w75K 8WpA== X-Gm-Message-State: ALoCoQl9fEXT/aIN/dNEds+stjNpH5p3NfWDfkMRFbESOeJyVl6nBluuzr1MYunppBk2k5te3oo0 MIME-Version: 1.0 X-Received: by 10.182.236.103 with SMTP id ut7mr13799896obc.3.1376926933771; Mon, 19 Aug 2013 08:42:13 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Mon, 19 Aug 2013 08:42:13 -0700 (PDT) X-Originating-IP: [192.1.255.218] In-Reply-To: <52122EAD.8010503@gondrom.org> References: <20130815014121.17800.33179.idtracker@ietfa.amsl.com> <520FFD18.2010008@gondrom.org> <52122EAD.8010503@gondrom.org> Date: Mon, 19 Aug 2013 11:42:13 -0400 Message-ID: From: Richard Barnes To: Tobias Gondrom Content-Type: multipart/alternative; boundary=001a11c30e50c4f4f404e44ec880 Cc: "draft-ietf-websec-x-frame-options@tools.ietf.org" , Barry Leiba , websec , The IESG , "websec-chairs@tools.ietf.org" Subject: Re: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 19 Aug 2013 15:42:19 -0000 --001a11c30e50c4f4f404e44ec880 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 19, 2013 at 10:41 AM, Tobias Gondrom wrote: > On 19/08/13 15:48, Richard Barnes wrote: > > > > > On Sun, Aug 18, 2013 at 1:58 AM, Barry Leiba wrote: > >> > (D2) It seems like this is a value that browsers might cache, to avoid >>> > unnecessary requests if the same page is framed in the future. If this >>> > is something browsers do today, please say so. >>> >>> Actually I like to push back in this case, as I don't think we should go >>> into implementation specific details that have no effect on the bits on >>> the wire nor on the effective behavior of the browser. >>> The X-Frame-Options header determines the behaviour for every individual >>> requested page regarding framing in another web page in the browser. >>> Whether the browser caches this information and compares the request >>> with an existing cache from a request from before AND if the value is >>> identical proceeds as before or whether the browser evaluates the >>> X-Frame-Options header on each request should not be specified in this >>> draft. >> >> >> I'll note also that this is particularly the case because this is >> documenting something that exists, but that isn't recommended for >> implementation. If this were a PS that we were recommending for new >> implementations, it might make more sense to talk about how to do caching >> for better implementations. >> >> Barry >> > > I understand. Caching is just another aspect of existing implementation > behavior that I think should be documented. > > Of course, I may be off base here. If nobody does it, and people think > it's patently obvious that you never would, then I could clear. > > --Richard > > > Richard, > > in short: I think, we really don't need and in fact should not discuss > caching of the existing implementations in this draft. > > Some info fyi: > caching has only very limited (or no) benefit here. Because the browser > has to check for every http-request of the resource whether the > X-Frame-Options header has been set and then act accordingly. It is also a > very simple check. > > And consider as a page itself might be dynamic, the header can change with > it, too. > > As mentioned in my answer before the only mini advantage of caching might > be that the browser sees the header is still the same as before (with a > simple TRUE/FALSE regex) and then doesn't have to evaluate the ruleset > again e.g. if ALLOW-FROM is set if you already did so in your previous > call. > But nearly all of the X-Frame-Options requests are DENY or SAMEORIGIN in > which case the comparison of the header with the previous one would not be > much cheaper than to just run the regex rule for the header itself. > > And also, as outlined in section 2.3.2.3., servers may generate > X-Frame-Options header responses depending on the request. > Example case: Consider that we have only one serialized-origin in the > ALLOW-FROM directive. Now imagine a user has multiple pages open in his > browser tabs with one of web page 1 from domain A and the second of web > page 2 from domain B both frame the same page from domain C with the > ALLOW-FROM directive. In that case the page needs to reply to both requests > with different X-Frame-Options headers, the first pointing to origin A, the > second to origin B. > But then many implementations don't support the ALLOW-FROM directive.... > > So to summarize my answer: we really don't need and in fact should not > discuss caching of the existing implementations. > > All the best, Tobias > Again, I'm not looking for an analysis of the merits here, just what current browsers do. It looks like Firefox doesn't cache anything [1], but I don't know about other browsers. If anyone does, then this document should warn people. If there are no known instances of caching, I'll just clear. In a related vein, the code below demonstrates that at least Firefox *will* accept a URI with ALLOW-FROM, and (correctly) do the comparison based on the origin of that URI. If other browsers do this, then with regard to (D3), it seems this document should probably say that the header *syntax* allows a URI, but the *comparison* is done based on the origin of the URI (Section 4 of RFC 6454). Thanks, --Richard [1] < http://dxr.mozilla.org/mozilla-central/source/docshell/base/nsDSURIContentListener.cpp#l361 > --001a11c30e50c4f4f404e44ec880 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Aug 19, 2013 at 10:41 AM, Tobias Gondrom = <tobias.= gondrom@gondrom.org> wrote:
=20 =20 =20
On 19/08/13 15:48, Richard Barnes wrote:



On Sun, Aug 18, 2013 at 1:58 AM, Barry Leiba <barryleiba@computer.org> wrote:
> (D2) It seems like this is a value that browsers might cache, to avoid
> unnecessary requests if the same page is framed in the future. =A0If this
> is something browsers do today, please say so.

Actually I like to push back in this case, as I don't think we should go
into implementation specific details that have no effect on the bits on
the wire nor on the effective behavior of the browser. The X-Frame-Options header determines the behaviour for every individual
requested page regarding framing in another web page in the browser.
Whether the browser caches this information and compares the request
with an existing cache from a request from before AND if the value is
identical proceeds as before or whether the browser evaluates the
X-Frame-Options header on each request should not be specified in this
draft.

=A0I'll note also that this is particularly the case because this is documenting something that exists, but that isn't recommended for implementation. =A0If this w= ere a PS that we were recommending for new implementations, it might make more sense to talk about how to do caching for better implementations.

Barry

I understand. =A0Caching is just another aspect of existing implementation behavior that I think should be documented. =A0

Of course, I may be off base here. =A0If nobody does it, and people think it's patently obvious that you never would, then I could clear.=A0

--Richard


Richard,

in short: I think, we really don't need and in fact should not discuss caching of the existing implementations in this draft.

Some info fyi:
caching has only very limited (or no) benefit here. Because the browser has to check for every http-request of the resource whether the X-Frame-Options header has been set and then act accordingly. It is also a very simple check.

And consider as a page itself might be dynamic, the header can change with it, too.

As mentioned in my answer before the only mini advantage of caching might be that the browser sees the header is still the same as before (with a simple TRUE/FALSE regex) and then doesn't have to evaluate the ruleset again e.g. if ALLOW-FROM is set if you already did so in your previous call.
But nearly all of the X-Frame-Options requests are DENY or SAMEORIGIN in which case the comparison of the header with the previous one would not be much cheaper than to just run the regex rule for the header itself.

And also, as outlined in section 2.3.2.3., servers may generate X-Frame-Options header responses depending on the request.
Example case: Consider that we have only one serialized-origin in the ALLOW-FROM directive. Now imagine a user has multiple pages open in his browser tabs with one of web page 1 from domain A and the second of web page 2 from domain B both frame the same page from domain C with the ALLOW-FROM directive. In that case the page needs to reply to both requests with different X-Frame-Options headers, the first pointing to origin A, the second to origin B.
But then many implementations don't support the ALLOW-FROM directive....

So to summarize my answer: we really don't need and in fact should not discuss caching of the existing implementations.

All the best, Tobias

Again, I= 'm not looking for an analysis of the merits here, just what current br= owsers do. =A0It looks like Firefox doesn't cache anything [1], but I d= on't know about other browsers. =A0If anyone does, then this document s= hould warn people. =A0If there are no known instances of caching, I'll = just clear.

In a related vein, the code below demonstrates that at = least Firefox *will* accept a URI with ALLOW-FROM, and (correctly) do the c= omparison based on the origin of that URI. =A0If other browsers do this, th= en with regard to (D3), it seems this document should probably say that the= header *syntax* allows a URI, but the *comparison* is done based on the or= igin of the URI (Section 4 of RFC 6454).

Thanks,
--Richard


--001a11c30e50c4f4f404e44ec880-- From barryleiba@gmail.com Mon Aug 19 10:43:35 2013 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 199EC11E82B1; Mon, 19 Aug 2013 10:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMw3rY96n7kA; Mon, 19 Aug 2013 10:43:34 -0700 (PDT) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF1B11E82AF; Mon, 19 Aug 2013 10:43:33 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id a11so1902046qen.11 for ; Mon, 19 Aug 2013 10:43:29 -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:message-id:subject :from:to:cc:content-type; bh=IbzP1Ny/4cL1iaiTF4hO4aX2sthSSiVPpD8QZziIzQk=; b=ACn8Sy6wAYVSNd2JHGYhpMftbR29p/ckAKGWaVzefKARo3fY6iSMT2zF8ygMMJwStQ hNJVB2W8Q9T8fSk7XcodWJ729HmAtHUf3qDHG5gYxE6CDTWU832Ha1BlGX6qZ6UncQLY N5cUnmrSiHzjkNbF9AR3YAaGe4j8WXwBNrWBbZ/9TUKf0xiTRLitJgIDzVHdEt3Wlz4u bbdJnA0Jb7aA7camrtwZNDuxTCnGiOpUA0zHsgj0H6/NJiDu0bZwaem+GkRoj8lyszVk sP/x0xFvGGWHa9riYn9QbxYIm4sBS9+IXI/0SQI0SzX3N8BoRxXLcJ6R3DLzQOZe25UM 7nag== MIME-Version: 1.0 X-Received: by 10.224.74.4 with SMTP id s4mr16868894qaj.51.1376934209339; Mon, 19 Aug 2013 10:43:29 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.59.211 with HTTP; Mon, 19 Aug 2013 10:43:29 -0700 (PDT) In-Reply-To: References: <20130815014121.17800.33179.idtracker@ietfa.amsl.com> <520FFD18.2010008@gondrom.org> <52122EAD.8010503@gondrom.org> Date: Mon, 19 Aug 2013 13:43:29 -0400 X-Google-Sender-Auth: 5cETe_QUf5MHI_2e7k6DGGwdNX0 Message-ID: From: Barry Leiba To: Richard Barnes Content-Type: text/plain; charset=ISO-8859-1 Cc: "draft-ietf-websec-x-frame-options@tools.ietf.org" , websec , The IESG , "websec-chairs@tools.ietf.org" Subject: Re: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 19 Aug 2013 17:43:35 -0000 Richard: 1. I disagree with you, but more to the point... 2. ...do you really think this meets the DISCUSS criteria? Barry On Mon, Aug 19, 2013 at 11:42 AM, Richard Barnes wrote: > > > > On Mon, Aug 19, 2013 at 10:41 AM, Tobias Gondrom > wrote: >> >> On 19/08/13 15:48, Richard Barnes wrote: >> >> >> >> >> On Sun, Aug 18, 2013 at 1:58 AM, Barry Leiba >> wrote: >>>> >>>> > (D2) It seems like this is a value that browsers might cache, to avoid >>>> > unnecessary requests if the same page is framed in the future. If >>>> > this >>>> > is something browsers do today, please say so. >>>> >>>> Actually I like to push back in this case, as I don't think we should go >>>> into implementation specific details that have no effect on the bits on >>>> the wire nor on the effective behavior of the browser. >>>> The X-Frame-Options header determines the behaviour for every individual >>>> requested page regarding framing in another web page in the browser. >>>> Whether the browser caches this information and compares the request >>>> with an existing cache from a request from before AND if the value is >>>> identical proceeds as before or whether the browser evaluates the >>>> X-Frame-Options header on each request should not be specified in this >>>> draft. >>> >>> >>> I'll note also that this is particularly the case because this is >>> documenting something that exists, but that isn't recommended for >>> implementation. If this were a PS that we were recommending for new >>> implementations, it might make more sense to talk about how to do caching >>> for better implementations. >>> >>> Barry >> >> >> I understand. Caching is just another aspect of existing implementation >> behavior that I think should be documented. >> >> Of course, I may be off base here. If nobody does it, and people think >> it's patently obvious that you never would, then I could clear. >> >> --Richard >> >> >> Richard, >> >> in short: I think, we really don't need and in fact should not discuss >> caching of the existing implementations in this draft. >> >> Some info fyi: >> caching has only very limited (or no) benefit here. Because the browser >> has to check for every http-request of the resource whether the >> X-Frame-Options header has been set and then act accordingly. It is also a >> very simple check. >> >> And consider as a page itself might be dynamic, the header can change with >> it, too. >> >> As mentioned in my answer before the only mini advantage of caching might >> be that the browser sees the header is still the same as before (with a >> simple TRUE/FALSE regex) and then doesn't have to evaluate the ruleset again >> e.g. if ALLOW-FROM is set if you already did so in your previous call. >> But nearly all of the X-Frame-Options requests are DENY or SAMEORIGIN in >> which case the comparison of the header with the previous one would not be >> much cheaper than to just run the regex rule for the header itself. >> >> And also, as outlined in section 2.3.2.3., servers may generate >> X-Frame-Options header responses depending on the request. >> Example case: Consider that we have only one serialized-origin in the >> ALLOW-FROM directive. Now imagine a user has multiple pages open in his >> browser tabs with one of web page 1 from domain A and the second of web page >> 2 from domain B both frame the same page from domain C with the ALLOW-FROM >> directive. In that case the page needs to reply to both requests with >> different X-Frame-Options headers, the first pointing to origin A, the >> second to origin B. >> But then many implementations don't support the ALLOW-FROM directive.... >> >> So to summarize my answer: we really don't need and in fact should not >> discuss caching of the existing implementations. >> >> All the best, Tobias > > > Again, I'm not looking for an analysis of the merits here, just what current > browsers do. It looks like Firefox doesn't cache anything [1], but I don't > know about other browsers. If anyone does, then this document should warn > people. If there are no known instances of caching, I'll just clear. > > In a related vein, the code below demonstrates that at least Firefox *will* > accept a URI with ALLOW-FROM, and (correctly) do the comparison based on the > origin of that URI. If other browsers do this, then with regard to (D3), it > seems this document should probably say that the header *syntax* allows a > URI, but the *comparison* is done based on the origin of the URI (Section 4 > of RFC 6454). > > Thanks, > --Richard > > [1] > > From bhill@paypal-inc.com Mon Aug 19 12:31:13 2013 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 5416F21F8EFE; Mon, 19 Aug 2013 12:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsjTnbNeg0Sf; Mon, 19 Aug 2013 12:31:09 -0700 (PDT) Received: from rhv-mipot-002.corp.ebay.com (rhv-mipot-002.corp.ebay.com [216.33.244.7]) by ietfa.amsl.com (Postfix) with ESMTP id 19B0721F9931; Mon, 19 Aug 2013 12:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=@paypal-inc.com; q=dns/txt; s=paypalcorp; t=1376940669; x=1408476669; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hmyhitMeGgiA9XdlAkO2e0fRkL8sYzHrzNjgAXm6GOs=; b=qKHmAvPbYB5OM9jUez1I+r9CuDzHhS9eeqPBNHnUJrZhlzZM0NmgOveJ 1qmTOzSYC9cHWbWZw4aHURkXThEXFH+Fde/mFfiOzpmbdCht3AZHVnNUB FU0EmZAxLTaKQtkqkIz/BtjE4nCPZUbW1Km2rMXw6nyEmyLbTcaD8oo02 I=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.89,914,1367996400"; d="scan'208";a="157177515" Received: from rhv-vtenf-002.corp.ebay.com (HELO DEN-EXMHT-002.corp.ebay.com) ([10.112.113.53]) by rhv-mipot-002.corp.ebay.com with ESMTP; 19 Aug 2013 12:31:09 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-002.corp.ebay.com ([fe80::cbe:ffa5:17f0:a24a%14]) with mapi id 14.03.0123.003; Mon, 19 Aug 2013 13:31:07 -0600 From: "Hill, Brad" To: Richard Barnes , The IESG , "tobias.gondrom@gondrom.org" Thread-Topic: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) Thread-Index: AQHOmVir9vsxQULiiEyJJmzuP9qAZ5mYgLPGgARwwbw= Date: Mon, 19 Aug 2013 19:31:07 +0000 Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E27BAF121@DEN-EXDDA-S12.corp.ebay.com> References: <20130815014121.17800.33179.idtracker@ietfa.amsl.com>, <370C9BEB4DD6154FA963E2F79ADC6F2E27BAD2A7@DEN-EXDDA-S12.corp.ebay.com> In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E27BAD2A7@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.241.19.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-websec-x-frame-options@tools.ietf.org" , "websec@ietf.org" , "websec-chairs@tools.ietf.org" Subject: Re: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 19 Aug 2013 19:31:13 -0000 I received a question as to whether all browsers really implement the top-l= evel only check, or if any do an immediate parent or ancestor walk. I coul= d guess, but I'd rather test. Here's a test case for public use:=0A= =0A= http://webappsec-test.info/~bhill2/XFO/XFO_Top.html=0A= =0A= I checked the latest IE, Chrome, Opera and Firefox and they all render the = innermost frame. (don't have a Safari instance handy at the moment to test = but welcome others' reports)=0A= =0A= -Brad=0A= ________________________________________=0A= From: Hill, Brad=0A= Sent: Friday, August 16, 2013 4:44 PM=0A= To: Richard Barnes; The IESG=0A= Cc: draft-ietf-websec-x-frame-options@tools.ietf.org; websec@ietf.org; webs= ec-chairs@tools.ietf.org=0A= Subject: RE: [websec] Richard Barnes' Discuss on draft-ietf-websec-x= -frame-options-09: (with DISCUSS and COMMENT)=0A= =0A= Additional comments inline.=0A= ________________________________________=0A= =0A= =0A= (D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI? In other=0A= words, what does it mean to send "X-Frame-Options: ALLOW-FROM=0A= https://example.com/this/is/a/path?query#fragment"?=0A= =0A= [Hill, Brad] Agreed.=0A= =0A= =0A= (D3) In the ALLOW-FROM: what does "top level context" mean? Do you=0A= really mean the top level here, as opposed to the next one up? For=0A= example, suppose A loads B in an iframe, and B loads C, and then C sends=0A= an X-Frame-Options header with ALLOW-FROM. Is the ALLOW-FROM origin=0A= compared to B or A? In either case, you should also note the attacks=0A= that remain. For example, if the answer is B, then B needs to use=0A= X-Frame-Options as well, or else, A can maliciously frame A within B. Or= =0A= if the answer is A, then C is trusting A not to load any malicious=0A= intermediate frames B.=0A= =0A= [Hill, Brad] This really does mean the top/final origin value in a frame a= ncestor=0A= chain walk. Browsers have implemented X-Frame-Options to check the=0A= Origin context that is topmost in the window or tab. (the _top target,=0A= representing the full, original browsing context, not just the immediate=0A= parent frame) This could be clarified perhaps, but is not incorrect.=0A= =0A= From rlb@ipv.sx Mon Aug 19 13:24:36 2013 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 9383A11E82E3 for ; Mon, 19 Aug 2013 13:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.813 X-Spam-Level: X-Spam-Status: No, score=-2.813 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyZ59w4ZatPl for ; Mon, 19 Aug 2013 13:24:32 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCF711E82E4 for ; Mon, 19 Aug 2013 13:24:02 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id n12so4336340oag.39 for ; Mon, 19 Aug 2013 13:24:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=p6FdZNyDOeOV1oNkNypFdc9aMIn4eZu/8VM0L1GPv/4=; b=TvbGjO3U/Sbb/GAhg5q8EzVAUaFieCUIVk2syR377A5bN5GMwQCH2VtIbEQe179ewO nmUATaexQxeQsknd+V+N94yl/h/EW5Qu/sYwoCLDUCb1yPicNMRVNAb5MM212XpVIP0S Rc5kPHkVt1py9OMejv1aibjOeXe5XaAn1VMOKGerDXyybZqH7x3o6jeUCEas7q7J6rnE 1mEKnud1XNSVj3ZUnHPaU1vNheLX3+aJlgUqZ+rGByix6/0qHud6DrEhlkWY6H/cmC8G ZP9IQW3NqMSes7BjkOt8cEnBfo3068PyixgNhN9f6LxMtqeZcwSy9HBA5DbjEbeG+WDd 9bNQ== X-Gm-Message-State: ALoCoQkxlV3IZ7JQ1bk5p9Z3DVllzSj+3RoagD9+FJoOpojTLeiJquqqDThsefirtexO7bIITwv+ MIME-Version: 1.0 X-Received: by 10.60.47.129 with SMTP id d1mr71640oen.84.1376943841616; Mon, 19 Aug 2013 13:24:01 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Mon, 19 Aug 2013 13:24:01 -0700 (PDT) X-Originating-IP: [2001:470:8:aff:c898:b483:6058:dadf] In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E27BAF121@DEN-EXDDA-S12.corp.ebay.com> References: <20130815014121.17800.33179.idtracker@ietfa.amsl.com> <370C9BEB4DD6154FA963E2F79ADC6F2E27BAD2A7@DEN-EXDDA-S12.corp.ebay.com> <370C9BEB4DD6154FA963E2F79ADC6F2E27BAF121@DEN-EXDDA-S12.corp.ebay.com> Date: Mon, 19 Aug 2013 16:24:01 -0400 Message-ID: From: Richard Barnes To: "Hill, Brad" Content-Type: multipart/alternative; boundary=001a11c303f28e406204e452b8d2 Cc: "draft-ietf-websec-x-frame-options@tools.ietf.org" , "websec@ietf.org" , The IESG , "websec-chairs@tools.ietf.org" Subject: Re: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 19 Aug 2013 20:24:36 -0000 --001a11c303f28e406204e452b8d2 Content-Type: text/plain; charset=ISO-8859-1 Safari also renders the innermost frame. On Mon, Aug 19, 2013 at 3:31 PM, Hill, Brad wrote: > I received a question as to whether all browsers really implement the > top-level only check, or if any do an immediate parent or ancestor walk. I > could guess, but I'd rather test. Here's a test case for public use: > > http://webappsec-test.info/~bhill2/XFO/XFO_Top.html > > I checked the latest IE, Chrome, Opera and Firefox and they all render the > innermost frame. (don't have a Safari instance handy at the moment to test > but welcome others' reports) > > -Brad > ________________________________________ > From: Hill, Brad > Sent: Friday, August 16, 2013 4:44 PM > To: Richard Barnes; The IESG > Cc: draft-ietf-websec-x-frame-options@tools.ietf.org; websec@ietf.org; > websec-chairs@tools.ietf.org > Subject: RE: [websec] Richard Barnes' Discuss on > draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) > > Additional comments inline. > ________________________________________ > > > (D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI? In other > words, what does it mean to send "X-Frame-Options: ALLOW-FROM > https://example.com/this/is/a/path?query#fragment"? > > [Hill, Brad] Agreed. > > > (D3) In the ALLOW-FROM: what does "top level context" mean? Do you > really mean the top level here, as opposed to the next one up? For > example, suppose A loads B in an iframe, and B loads C, and then C sends > an X-Frame-Options header with ALLOW-FROM. Is the ALLOW-FROM origin > compared to B or A? In either case, you should also note the attacks > that remain. For example, if the answer is B, then B needs to use > X-Frame-Options as well, or else, A can maliciously frame A within B. Or > if the answer is A, then C is trusting A not to load any malicious > intermediate frames B. > > [Hill, Brad] This really does mean the top/final origin value in a frame > ancestor > chain walk. Browsers have implemented X-Frame-Options to check the > Origin context that is topmost in the window or tab. (the _top target, > representing the full, original browsing context, not just the immediate > parent frame) This could be clarified perhaps, but is not incorrect. > > --001a11c303f28e406204e452b8d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Safari also renders the innermost frame.


On Mon, Aug 19, 2013 at= 3:31 PM, Hill, Brad <bhill@paypal-inc.com> wrote:
I received a question as to whether all brow= sers really implement the top-level only check, or if any do an immediate p= arent or ancestor walk. =A0I could guess, but I'd rather test. =A0Here&= #39;s a test case for public use:

http://webappsec-test.info/~bhill2/XFO/XFO_Top.html

I checked the latest IE, Chrome, Opera and Firefox and they all render the = innermost frame. (don't have a Safari instance handy at the moment to t= est but welcome others' reports)

-Brad
________________________________________
From: Hill, Brad
Sent: Friday, August 16, 2013 4:44 PM
To: Richard Barnes; The IESG
Cc: dra= ft-ietf-websec-x-frame-options@tools.ietf.org; websec@ietf.org; websec-chairs@tools.ietf.org
Subject: RE: [websec] Richard Barnes' Discuss on =A0 =A0 =A0 =A0draft-i= etf-websec-x-frame-options-09: =A0 (with DISCUSS and COMMENT)

Additional comments inline.
________________________________________


(D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI? =A0In ot= her
words, what does it mean to send "X-Frame-Options: ALLOW-FROM
https://example.com/this/is/a/path?query#fragment"?

[Hill, Brad] Agreed.


(D3) In the ALLOW-FROM: what does "top level context" mean? =A0Do= you
really mean the top level here, as opposed to the next one up? =A0For
example, suppose A loads B in an iframe, and B loads C, and then C sends an X-Frame-Options header with ALLOW-FROM. =A0Is the ALLOW-FROM origin
compared to B or A? =A0In either case, you should also note the attacks
that remain. =A0For example, if the answer is B, then B needs to use
X-Frame-Options as well, or else, A can maliciously frame A within B. =A0Or=
if the answer is A, then C is trusting A not to load any malicious
intermediate frames B.

[Hill, Brad] =A0This really does mean the top/final origin value in a frame= ancestor
chain walk. =A0Browsers have implemented X-Frame-Options to check the
Origin context that is topmost in the window or tab. =A0(the _top target, representing the full, original browsing context, not just the immediate parent frame) =A0This could be clarified perhaps, but is not incorrect.


--001a11c303f28e406204e452b8d2-- From tobias.gondrom@gondrom.org Mon Aug 19 13:27:45 2013 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 B853521F90FD for ; Mon, 19 Aug 2013 13:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[AWL=0.001, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKHzjE7g7r8m for ; Mon, 19 Aug 2013 13:27:32 -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 8286611E82DA for ; Mon, 19 Aug 2013 13:27:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=S5e8XNODGg6wjMUkt6hu8stSzO6zXR1jCnc3Dzpvs8pG172SMLSRymkyzHWSYvPc+YOC0Ls1bI/a0YVSErcQwInjMTPeOTz2n/zoxPgy0qTjLB7iIXvhxQes+g0HgncP; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 14004 invoked from network); 19 Aug 2013 22:27:25 +0200 Received: from port-83-236-131-2.static.qsc.de (HELO ?10.13.163.52?) (83.236.131.2) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Aug 2013 22:27:24 +0200 Message-ID: <52127FAB.4020501@gondrom.org> Date: Mon, 19 Aug 2013 22:27:23 +0200 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: bhill@paypal-inc.com References: <20130815014121.17800.33179.idtracker@ietfa.amsl.com>, <370C9BEB4DD6154FA963E2F79ADC6F2E27BAD2A7@DEN-EXDDA-S12.corp.ebay.com> <370C9BEB4DD6154FA963E2F79ADC6F2E27BAF121@DEN-EXDDA-S12.corp.ebay.com> In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E27BAF121@DEN-EXDDA-S12.corp.ebay.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, iesg@ietf.org, websec-chairs@tools.ietf.org Subject: Re: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 19 Aug 2013 20:27:45 -0000 On 19/08/13 21:31, Hill, Brad wrote: > I received a question as to whether all browsers really implement the top-level only check, or if any do an immediate parent or ancestor walk. I could guess, but I'd rather test. Here's a test case for public use: > > http://webappsec-test.info/~bhill2/XFO/XFO_Top.html > > I checked the latest IE, Chrome, Opera and Firefox and they all render the innermost frame. (don't have a Safari instance handy at the moment to test but welcome others' reports) I just tested Safari and can confirm that they do render the innermost frame. (i.e. render based on the top-level frame.) Strangely: I found in my old notes from the first version of the draft from 2011/2012 that not all browsers would use the same algorithm for X-Frame-Options: SAMEORIGIN. But obviously they do now (as tested and verified). I will adjust the text in version -11 for section 5 accordingly and remove in section 5 sub-bullet a). Special thanks to Brad for creating the test web page and cross-verifying. Thanks, Tobias Ps.: apologies, it may take up to 48 hours for me to submit the new text for version-11 as I will have a busy work day tomorrow. :-( > > -Brad > ________________________________________ > From: Hill, Brad > Sent: Friday, August 16, 2013 4:44 PM > To: Richard Barnes; The IESG > Cc: draft-ietf-websec-x-frame-options@tools.ietf.org; websec@ietf.org; websec-chairs@tools.ietf.org > Subject: RE: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) > > Additional comments inline. > ________________________________________ > > > (D3) Shouldn't ALLOW-FROM be followed by an origin, not a URI? In other > words, what does it mean to send "X-Frame-Options: ALLOW-FROM > https://example.com/this/is/a/path?query#fragment"? > > [Hill, Brad] Agreed. > > > (D3) In the ALLOW-FROM: what does "top level context" mean? Do you > really mean the top level here, as opposed to the next one up? For > example, suppose A loads B in an iframe, and B loads C, and then C sends > an X-Frame-Options header with ALLOW-FROM. Is the ALLOW-FROM origin > compared to B or A? In either case, you should also note the attacks > that remain. For example, if the answer is B, then B needs to use > X-Frame-Options as well, or else, A can maliciously frame A within B. Or > if the answer is A, then C is trusting A not to load any malicious > intermediate frames B. > > [Hill, Brad] This really does mean the top/final origin value in a frame ancestor > chain walk. Browsers have implemented X-Frame-Options to check the > Origin context that is topmost in the window or tab. (the _top target, > representing the full, original browsing context, not just the immediate > parent frame) This could be clarified perhaps, but is not incorrect. > From rlb@ipv.sx Mon Aug 19 13:28:01 2013 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 B392111E82E8 for ; Mon, 19 Aug 2013 13:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.83 X-Spam-Level: X-Spam-Status: No, score=-2.83 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFLSPg7Ka-qm for ; Mon, 19 Aug 2013 13:27:52 -0700 (PDT) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id CBF8711E82D2 for ; Mon, 19 Aug 2013 13:27:49 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wo10so6097191obc.41 for ; Mon, 19 Aug 2013 13:27:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BTF8AYvVZTBoCm83YaGnvS3kfIrJ79lSIEEwUOigiGQ=; b=BGPals33eKFKWgYV4NfjDriXzpr0WvpRRu2TGyoPqjFZRZW/sfKtVMgcuGh3EMzTCv 2QSkuT+0KfdFrl5LcDBlyVxRAd8WpA4szCKa9pUneD896CVIKFUpjC4YGFI5R2+HpLOe pcO2vJAke65LAQ/4/i1hLn57o3vrg5nqCPnnjhfP1kgfqHLNbnT5Wqd86J8Tr9pQNPo8 +FTLDY42F265E5rnGgKvAHcri7IPnXfjVRFGX0wwDAxrii/IPkUakPJB9a0zJ9ZwJBvG CxKpNf8s53m+jwvefkVhpPpC5yqj/FY+TIlJMhVoQa/Bhp4K2cUMjTjzt5Zqn/pun4ZN PpJQ== X-Gm-Message-State: ALoCoQmpXEa5tuwheqjxX8/GklzTWZn9Mp234EO9pxKZFlb/bbvW1qvB0SojtSSdrkcBjG6Dml3N MIME-Version: 1.0 X-Received: by 10.60.121.103 with SMTP id lj7mr14865854oeb.25.1376944069348; Mon, 19 Aug 2013 13:27:49 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Mon, 19 Aug 2013 13:27:49 -0700 (PDT) X-Originating-IP: [2001:470:8:aff:c898:b483:6058:dadf] In-Reply-To: References: <20130815014121.17800.33179.idtracker@ietfa.amsl.com> <520FFD18.2010008@gondrom.org> <52122EAD.8010503@gondrom.org> Date: Mon, 19 Aug 2013 16:27:49 -0400 Message-ID: From: Richard Barnes To: Barry Leiba Content-Type: multipart/alternative; boundary=047d7b414e9e211d7f04e452c61c Cc: "draft-ietf-websec-x-frame-options@tools.ietf.org" , websec , The IESG , "websec-chairs@tools.ietf.org" Subject: Re: [websec] Richard Barnes' Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 19 Aug 2013 20:28:01 -0000 --047d7b414e9e211d7f04e452c61c Content-Type: text/plain; charset=ISO-8859-1 My understanding of the goal of "existing state of the art" documents like this is to enable users of the relevant technology to understand how it behaves. If there is caching behavior, then users need to know about it (in particular, web sites that might set X-Frame-Options). This seems like a potentially significant interop issue, so I was going to hold the DISCUSS until someone told me whether there's an issue there or not, i.e., whether there's any caching behavior out in the wild. --Richard On Mon, Aug 19, 2013 at 1:43 PM, Barry Leiba wrote: > Richard: > > 1. I disagree with you, but more to the point... > > 2. ...do you really think this meets the DISCUSS criteria? > > Barry > > On Mon, Aug 19, 2013 at 11:42 AM, Richard Barnes wrote: > > > > > > > > On Mon, Aug 19, 2013 at 10:41 AM, Tobias Gondrom > > wrote: > >> > >> On 19/08/13 15:48, Richard Barnes wrote: > >> > >> > >> > >> > >> On Sun, Aug 18, 2013 at 1:58 AM, Barry Leiba > >> wrote: > >>>> > >>>> > (D2) It seems like this is a value that browsers might cache, to > avoid > >>>> > unnecessary requests if the same page is framed in the future. If > >>>> > this > >>>> > is something browsers do today, please say so. > >>>> > >>>> Actually I like to push back in this case, as I don't think we should > go > >>>> into implementation specific details that have no effect on the bits > on > >>>> the wire nor on the effective behavior of the browser. > >>>> The X-Frame-Options header determines the behaviour for every > individual > >>>> requested page regarding framing in another web page in the browser. > >>>> Whether the browser caches this information and compares the request > >>>> with an existing cache from a request from before AND if the value is > >>>> identical proceeds as before or whether the browser evaluates the > >>>> X-Frame-Options header on each request should not be specified in this > >>>> draft. > >>> > >>> > >>> I'll note also that this is particularly the case because this is > >>> documenting something that exists, but that isn't recommended for > >>> implementation. If this were a PS that we were recommending for new > >>> implementations, it might make more sense to talk about how to do > caching > >>> for better implementations. > >>> > >>> Barry > >> > >> > >> I understand. Caching is just another aspect of existing implementation > >> behavior that I think should be documented. > >> > >> Of course, I may be off base here. If nobody does it, and people think > >> it's patently obvious that you never would, then I could clear. > >> > >> --Richard > >> > >> > >> Richard, > >> > >> in short: I think, we really don't need and in fact should not discuss > >> caching of the existing implementations in this draft. > >> > >> Some info fyi: > >> caching has only very limited (or no) benefit here. Because the browser > >> has to check for every http-request of the resource whether the > >> X-Frame-Options header has been set and then act accordingly. It is > also a > >> very simple check. > >> > >> And consider as a page itself might be dynamic, the header can change > with > >> it, too. > >> > >> As mentioned in my answer before the only mini advantage of caching > might > >> be that the browser sees the header is still the same as before (with a > >> simple TRUE/FALSE regex) and then doesn't have to evaluate the ruleset > again > >> e.g. if ALLOW-FROM is set if you already did so in your previous call. > >> But nearly all of the X-Frame-Options requests are DENY or SAMEORIGIN in > >> which case the comparison of the header with the previous one would not > be > >> much cheaper than to just run the regex rule for the header itself. > >> > >> And also, as outlined in section 2.3.2.3., servers may generate > >> X-Frame-Options header responses depending on the request. > >> Example case: Consider that we have only one serialized-origin in the > >> ALLOW-FROM directive. Now imagine a user has multiple pages open in his > >> browser tabs with one of web page 1 from domain A and the second of web > page > >> 2 from domain B both frame the same page from domain C with the > ALLOW-FROM > >> directive. In that case the page needs to reply to both requests with > >> different X-Frame-Options headers, the first pointing to origin A, the > >> second to origin B. > >> But then many implementations don't support the ALLOW-FROM directive.... > >> > >> So to summarize my answer: we really don't need and in fact should not > >> discuss caching of the existing implementations. > >> > >> All the best, Tobias > > > > > > Again, I'm not looking for an analysis of the merits here, just what > current > > browsers do. It looks like Firefox doesn't cache anything [1], but I > don't > > know about other browsers. If anyone does, then this document should > warn > > people. If there are no known instances of caching, I'll just clear. > > > > In a related vein, the code below demonstrates that at least Firefox > *will* > > accept a URI with ALLOW-FROM, and (correctly) do the comparison based on > the > > origin of that URI. If other browsers do this, then with regard to > (D3), it > > seems this document should probably say that the header *syntax* allows a > > URI, but the *comparison* is done based on the origin of the URI > (Section 4 > > of RFC 6454). > > > > Thanks, > > --Richard > > > > [1] > > < > http://dxr.mozilla.org/mozilla-central/source/docshell/base/nsDSURIContentListener.cpp#l361 > > > > > --047d7b414e9e211d7f04e452c61c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My understanding of the goal of "existing state of th= e art" documents like this is to enable users of the relevant technolo= gy to understand how it behaves. =A0If there is caching behavior, then user= s need to know about it (in particular, web sites that might set X-Frame-Op= tions). =A0This seems like a potentially significant interop issue, so I wa= s going to hold the DISCUSS until someone told me whether there's an is= sue there or not, i.e., whether there's any caching behavior out in the= wild. =A0

--Richard




On Mon, Aug 19, 20= 13 at 1:43 PM, Barry Leiba <barryleiba@computer.org> w= rote:
Richard:

1. I disagree with you, but more to the point...

2. ...do you really think this meets the DISCUSS criteria?

Barry

On Mon, Aug 19, 2013 at 11:42 AM, Richard Barnes <rlb@ipv.sx> wrote:<= br> >
>
>
> On Mon, Aug 19, 2013 at 10:41 AM, Tobias Gondrom
> <tobias.gondrom@gondr= om.org> wrote:
>>
>> On 19/08/13 15:48, Richard Barnes wrote:
>>
>>
>>
>>
>> On Sun, Aug 18, 2013 at 1:58 AM, Barry Leiba <barryleiba@computer.org>
>> wrote:
>>>>
>>>> > (D2) It seems like this is a value that browsers migh= t cache, to avoid
>>>> > unnecessary requests if the same page is framed in th= e future. =A0If
>>>> > this
>>>> > is something browsers do today, please say so.
>>>>
>>>> Actually I like to push back in this case, as I don't = think we should go
>>>> into implementation specific details that have no effect o= n the bits on
>>>> the wire nor on the effective behavior of the browser.
>>>> The X-Frame-Options header determines the behaviour for ev= ery individual
>>>> requested page regarding framing in another web page in th= e browser.
>>>> Whether the browser caches this information and compares t= he request
>>>> with an existing cache from a request from before AND if t= he value is
>>>> identical proceeds as before or whether the browser evalua= tes the
>>>> X-Frame-Options header on each request should not be speci= fied in this
>>>> draft.
>>>
>>>
>>> =A0I'll note also that this is particularly the case becau= se this is
>>> documenting something that exists, but that isn't recommen= ded for
>>> implementation. =A0If this were a PS that we were recommending= for new
>>> implementations, it might make more sense to talk about how to= do caching
>>> for better implementations.
>>>
>>> Barry
>>
>>
>> I understand. =A0Caching is just another aspect of existing implem= entation
>> behavior that I think should be documented.
>>
>> Of course, I may be off base here. =A0If nobody does it, and peopl= e think
>> it's patently obvious that you never would, then I could clear= .
>>
>> --Richard
>>
>>
>> Richard,
>>
>> in short: I think, we really don't need and in fact should not= discuss
>> caching of the existing implementations in this draft.
>>
>> Some info fyi:
>> caching has only very limited (or no) benefit here. Because the br= owser
>> has to check for every http-request of the resource whether the >> X-Frame-Options header has been set and then act accordingly. It i= s also a
>> very simple check.
>>
>> And consider as a page itself might be dynamic, the header can cha= nge with
>> it, too.
>>
>> As mentioned in my answer before the only mini advantage of cachin= g might
>> be that the browser sees the header is still the same as before (w= ith a
>> simple TRUE/FALSE regex) and then doesn't have to evaluate the= ruleset again
>> e.g. if ALLOW-FROM is set if you already did so in your previous c= all.
>> But nearly all of the X-Frame-Options requests are DENY or SAMEORI= GIN in
>> which case the comparison of the header with the previous one woul= d not be
>> much cheaper than to just run the regex rule for the header itself= .
>>
>> And also, as outlined in section 2.3.2.3., servers may generate >> X-Frame-Options header responses depending on the request.
>> Example case: Consider that we have only one serialized-origin in = the
>> ALLOW-FROM directive. Now imagine a user has multiple pages open i= n his
>> browser tabs with one of web page 1 from domain A and the second o= f web page
>> 2 from domain B both frame the same page from domain C with the AL= LOW-FROM
>> directive. In that case the page needs to reply to both requests w= ith
>> different X-Frame-Options headers, the first pointing to origin A,= the
>> second to origin B.
>> But then many implementations don't support the ALLOW-FROM dir= ective....
>>
>> So to summarize my answer: we really don't need and in fact sh= ould not
>> discuss caching of the existing implementations.
>>
>> All the best, Tobias
>
>
> Again, I'm not looking for an analysis of the merits here, just wh= at current
> browsers do. =A0It looks like Firefox doesn't cache anything [1], = but I don't
> know about other browsers. =A0If anyone does, then this document shoul= d warn
> people. =A0If there are no known instances of caching, I'll just c= lear.
>
> In a related vein, the code below demonstrates that at least Firefox *= will*
> accept a URI with ALLOW-FROM, and (correctly) do the comparison based = on the
> origin of that URI. =A0If other browsers do this, then with regard to = (D3), it
> seems this document should probably say that the header *syntax* allow= s a
> URI, but the *comparison* is done based on the origin of the URI (Sect= ion 4
> of RFC 6454).
>
> Thanks,
> --Richard
>
> [1]
> <http://dxr.mozilla.= org/mozilla-central/source/docshell/base/nsDSURIContentListener.cpp#l361>
>

--047d7b414e9e211d7f04e452c61c-- From turners@ieca.com Mon Aug 19 15:37:52 2013 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 AFA7F11E81A6 for ; Mon, 19 Aug 2013 15:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.795 X-Spam-Level: X-Spam-Status: No, score=-101.795 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id disRXBPZkggA for ; Mon, 19 Aug 2013 15:37:46 -0700 (PDT) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [67.18.88.8]) by ietfa.amsl.com (Postfix) with ESMTP id 542A611E8182 for ; Mon, 19 Aug 2013 15:37:41 -0700 (PDT) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id 4B6E534288712; Mon, 19 Aug 2013 17:37:37 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway15.websitewelcome.com (Postfix) with ESMTP id 33C88342886C6 for ; Mon, 19 Aug 2013 17:37:37 -0500 (CDT) Received: from [96.231.225.44] (port=63866 helo=thunderfish.local) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VBY4u-0003oY-P0; Mon, 19 Aug 2013 17:37:36 -0500 Message-ID: <52129E2F.1010700@ieca.com> Date: Mon, 19 Aug 2013 18:37:35 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Yoav Nir References: <20130814161444.6218.82572.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.225.44]:63866 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 20 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Cc: "" , "" , The IESG , "" Subject: Re: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT) 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, 19 Aug 2013 22:37:52 -0000 This works for me I cleared. Thanks! spt On 8/18/13 11:09 AM, Yoav Nir wrote: > > On Aug 14, 2013, at 7:14 PM, Sean Turner wrote: > >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> It's interesting to note that this draft says there's a problem with >> folks not checking the origins of the entire ancestor tree of names of >> the framing resource - but then doesn't say that sounds like a good idea >> do it. I can see the argument that might be made that this draft is just >> documenting what's done now, but shouldn't we take the opportunity to do >> more and recommend something along the lines of "The entire ancestor tree >> of names of the framing resource SHOULD be checked to mitigate the risk >> of attacks in multiple-nested scenarios" or something like that? > > Hi Sean. The text has changed in version -10. There are still no RFC 2119 words there and no recommendations to browser vendors (as we take those to be immovable objects (the implementation, not the vendors)), but the recommendations to web developers have been changed from "should be aware" to "should make sure". Since we are documenting a given situation, which we hope will be changed by the CSP work, and since web developers cannot ignore the status quo (when *is* a good time to stop targetting IE8?), does this text change satisfy you? > > OLD: > For example, if a resource on origin A embeds > untrusted content from origin B, that untrusted content can embed > another resource from origin A with an X-Frame-Options: SAMEORIGIN > policy and that check would pass if the user agent only verifies the > top-level browsing context. Therefore web developers should be aware > that embedding content from other sites can leave their web pages > vulnerable to clickjacking even if the X-Frame-Options header is > used. > > NEW: > a. If the browser implementation evaluates based on the origins of > the framed page and the framing page: > Suppose a web page A (from origin 1) embeds a web page B (from > origin 2) in a frame or iframe which in turn embeds web page C > (from origin 2) using the x-frame-options header in a frame. In > this case web page B needs to use X-Frame-Options as well, or > else a malicious page A could frame page B and with that > indirectly also page C. Therefore web developers should make > sure that all pages from an origin that is allowed to frame a > given resource web page C should also use X-Frame-Options or > otherwise risk exposing web page C indirectly to Clickjacking > attacks. And so forth recursively until the top-level browsing- > context (i.e. most outer frame) is reached. > > b. If the browser implementation evaluates based on the origin of > the framed page and the top-level browsing-context (i.e. most > outer frame): > If a resource from origin A embeds untrusted content from origin > B, that untrusted content can embed another resource from origin > A with an X-Frame-Options: SAMEORIGIN policy and that check would > pass if the user agent only verifies the top-level browsing > context. Therefore web developers should be aware that embedding > content from other sites can leave their web pages vulnerable to > clickjacking even if the X-Frame-Options header is used. > > Yoav > > From trevp@trevp.net Mon Aug 19 17:44:18 2013 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 2911E11E8311 for ; Mon, 19 Aug 2013 17:44:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JF+GBT8sRb2o for ; Mon, 19 Aug 2013 17:44:12 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1025711E8192 for ; Mon, 19 Aug 2013 17:44:11 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id l18so1735855wgh.0 for ; Mon, 19 Aug 2013 17:44:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=TWF4DgcMG7wyjyfazCBbaZKion5ojw4wRr3IjUFxvo4=; b=Tf8LWK4IGuGiRuKzX/TZAS6XIRgJLhC7wO/mvvQJjbumlqxewo2FPg5w92MLtOKprx 3nGIYljxSNaSoKSX0UPIFCwkbsm9Exbk3svrS1NT+4oAhoTaDAKlSoJOzDmLc7j5Uhiq N47Lj7zwwGUxkthSg2iQxN3mBEhQSZdM6m9ftAgsk1SHNwMlMT1B5l6P6lmVZLYnSx3V AFNhmkjhw3V4YX5biXMqGQpU8E1xRFoATxrXy8usV5ONvfdirFofITKs81wn5f6s01c+ EsrYkbpr54IANihPP94RQImKSw9mpjKWbUiLRfL0bm3fpU9smjDQo2XJcTrZHQCLA5tK Kxjw== X-Gm-Message-State: ALoCoQmFFPsI5d2Rx/GYMLBngcL8inqyRDFBcVn9JfQQ+FWWAw3tDuCswl2TaUmVCEXIkybxLfyv MIME-Version: 1.0 X-Received: by 10.180.100.225 with SMTP id fb1mr10209056wib.22.1376959451196; Mon, 19 Aug 2013 17:44:11 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Mon, 19 Aug 2013 17:44:11 -0700 (PDT) X-Originating-IP: [208.184.35.186] Date: Mon, 19 Aug 2013 17:44:11 -0700 Message-ID: From: Trevor Perrin To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [websec] Resuming the cookie discussion 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, 20 Aug 2013 00:44:18 -0000 To pick this up again, it would be great to have: (a) Some cryptographic binding for cookies, either using asymmetric crypto (ChannelID) or symmetric (Smart Cookies), to prevent them being useable when transferred between browsers. (b) Some origin-binding for cookies to prevent them leaking to subdomains and being forced by other domains (Origin Cookies). Both (a) and (b) address the threats of cookie-forcing and cookie-stealing, but neither is a complete replacement for the other: (a) Cryptographic binding of cookies would not prevent an attacker who controls related domains from: - deleting cookies - stealing a cookie from user A and then forcing it back to A, later, to roll-back the cookie to an earlier value (b) Origin binding of cookies would not protect against a failure in TLS confidentiality that exposes the cookie's value. Questions ========= * Are both (a) and (b) worth doing? Should we prioritize one? * Regarding ChannelID vs Smart Cookies: ChannelID provides a "bindable" identifier that could be used for other things besides cookies (OAuth tokens? other?). But it also requires TLS changes and an additional signing operation on the client. The Smart Cookie approach is more efficient but also narrowly scoped to cookies. Do people have other arguments, or strong feelings, one way or the other? Trevor From ynir@checkpoint.com Tue Aug 20 01:39:52 2013 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 9F0FA11E80F7 for ; Tue, 20 Aug 2013 01:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.687 X-Spam-Level: X-Spam-Status: No, score=-10.687 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jItF6yIae1p5 for ; Tue, 20 Aug 2013 01:39:48 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8E21D11E81B0 for ; Tue, 20 Aug 2013 01:39:47 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7K8dit4008885; Tue, 20 Aug 2013 11:39:45 +0300 X-CheckPoint: {52132B50-12-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Tue, 20 Aug 2013 11:39:44 +0300 From: Yoav Nir To: Trevor Perrin Thread-Topic: [websec] Resuming the cookie discussion Thread-Index: AQHOnT5tv9RHi7L0vE2lM/a3ZyRompmdlOUA Date: Tue, 20 Aug 2013 08:39:44 +0000 Message-ID: <046479A5-F6C1-4304-AA3A-C7D4056163A3@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.143] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11252f5ea9190efc4fd3c6dee4acc47a99c5d2c5d3 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] Resuming the cookie discussion 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, 20 Aug 2013 08:39:52 -0000 Hi Trevor.=20 I think (a) is definitely worth doing, but I also think that (b) can be don= e along the way. Is there some reason why (a) and (b) can't be requirements= filled by a single mechanism? Regarding smart cookies vs channel ID: Not changing TLS is a definite advan= tage of Smart Cookies. Reading that message again ([1]), I'm not sure wheth= er the cookie_binding is necessary, but I get that it protects against pass= ing cookies. The only issue I have with this is that it relies on extractor= s, and so will break at TLS proxies. While this is good from a security per= spective, it's a killer for deployment. I think that Channel ID works in th= e presence of proxies, assuming the proxies are updated and move the encryp= ted extension unchanged. Yoav [1] http://www.ietf.org/mail-archive/web/websec/current/msg01729.html On Aug 20, 2013, at 3:44 AM, Trevor Perrin wrote: > To pick this up again, it would be great to have: >=20 > (a) Some cryptographic binding for cookies, either using asymmetric > crypto (ChannelID) or symmetric (Smart Cookies), to prevent them being > useable when transferred between browsers. >=20 > (b) Some origin-binding for cookies to prevent them leaking to > subdomains and being forced by other domains (Origin Cookies). >=20 >=20 > Both (a) and (b) address the threats of cookie-forcing and > cookie-stealing, but neither is a complete replacement for the other: >=20 > (a) Cryptographic binding of cookies would not prevent an attacker > who controls related domains from: > - deleting cookies > - stealing a cookie from user A and then forcing it back to A, > later, to roll-back the cookie to an earlier value >=20 > (b) Origin binding of cookies would not protect against a failure in > TLS confidentiality that exposes the cookie's value. >=20 >=20 > Questions > =3D=3D=3D=3D=3D=3D=3D=3D=3D > * Are both (a) and (b) worth doing? Should we prioritize one? >=20 > * Regarding ChannelID vs Smart Cookies: ChannelID provides a > "bindable" identifier that could be used for other things besides > cookies (OAuth tokens? other?). But it also requires TLS changes and > an additional signing operation on the client. The Smart Cookie > approach is more efficient but also narrowly scoped to cookies. >=20 > Do people have other arguments, or strong feelings, one way or the other? >=20 >=20 > Trevor > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From trevp@trevp.net Tue Aug 20 11:01:27 2013 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 7452B11E8117 for ; Tue, 20 Aug 2013 11:01:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9XKd3wy7eX7 for ; Tue, 20 Aug 2013 11:01:19 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2D30511E8114 for ; Tue, 20 Aug 2013 11:01:18 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id e12so667162wgh.33 for ; Tue, 20 Aug 2013 11:01:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ub3z18A00MAgS4+Rntnri4UIpAL2zO6GJ3nLppn6e+c=; b=M4uTKG9eREOlG1Qu4pjvPT29Tfe18SCEDP42C8pEcSDK4adoTvSyAU2tEqOUwGeOC5 Nm7KyH9qY2qTGZDjWh45AV3+/KSGda3PMfW3s4c/robpURlxgFx81KbVmz6dNLDWvE/C tkDZh0aMmmqRGNGWNFE3Rt3VKxVr4vLVlQ/pz+ENpO0zJkZ0C9PccglwdTbNFOaauVHs 35G1S2AAcoOKKdXBJ0Shcx8SQofzoBFxh29BRs5EUkDrcdadaF4wasLgLSrgv29ia4K/ WvNlIhAkh9Alc1p5vP4YwzF4tduWRvrZINuqB0Bddsf6jNyEODqknyGyHvBnjqJcNtQI 58Tw== X-Gm-Message-State: ALoCoQnUGaR8o7i4OG4d/9wErNFj9mizUlODfJUhRD5S6pXtgB1+nGUlwT9AyOhWEs1r1uibreob MIME-Version: 1.0 X-Received: by 10.180.100.225 with SMTP id fb1mr13273782wib.22.1377021675457; Tue, 20 Aug 2013 11:01:15 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Tue, 20 Aug 2013 11:01:15 -0700 (PDT) X-Originating-IP: [208.184.35.186] In-Reply-To: <046479A5-F6C1-4304-AA3A-C7D4056163A3@checkpoint.com> References: <046479A5-F6C1-4304-AA3A-C7D4056163A3@checkpoint.com> Date: Tue, 20 Aug 2013 11:01:15 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] Resuming the cookie discussion 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, 20 Aug 2013 18:01:27 -0000 On Tue, Aug 20, 2013 at 1:39 AM, Yoav Nir wrote: > Hi Trevor. > > I think (a) is definitely worth doing, but I also think that (b) can be done along the way. Interesting... If we were to prioritize them, I'd argue the reverse: (b) ("Origin Cookies") strikes me as the most economical, since it fully addresses cookie-forcing and stealing provided TLS is secure. > Is there some reason why (a) and (b) can't be requirements filled by a single mechanism? That's exactly what Smart Cookies attempt - they have origin-binding, *and* cryptographic-binding via MAC. But I don't know whether that's the best approach. It might be easier to push things like ChannelID and Origin Cookies separately. > Regarding smart cookies vs channel ID: Not changing TLS is a definite advantage of Smart Cookies. Reading that message again ([1]), I'm not sure whether the cookie_binding is necessary, It's necessary so the transmitted MAC doesn't become a "bearer token" that could be re-used by anyone. > but I get that it protects against passing cookies. The only issue I have with this > is that it relies on extractors, and so will break at TLS proxies. While this is good > from a security perspective, it's a killer for deployment. I think that Channel ID > works in the presence of proxies, assuming the proxies are updated and move > the encrypted extension unchanged. I assumed that both Smart Cookies and ChannelID would break at TLS proxies until those proxies are updated to pass some information downstream. And then would work. Since Smart Cookies don't affect the bytes-on-the-wire, whereas ChannelID modifies the Handshake protocol, I was also assuming Smart Cookies would be the easier change. Is that wrong? Trevor From ynir@checkpoint.com Tue Aug 20 21:03:14 2013 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 BE2DF11E80FF for ; Tue, 20 Aug 2013 21:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.713 X-Spam-Level: X-Spam-Status: No, score=-10.713 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYqq3Q+erg9q for ; Tue, 20 Aug 2013 21:03:09 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 91D9E11E80E7 for ; Tue, 20 Aug 2013 21:03:08 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7L436ub004222; Wed, 21 Aug 2013 07:03:07 +0300 X-CheckPoint: {52143BFA-14-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Wed, 21 Aug 2013 07:03:05 +0300 From: Yoav Nir To: Trevor Perrin Thread-Topic: [websec] Resuming the cookie discussion Thread-Index: AQHOnT5tv9RHi7L0vE2lM/a3ZyRompmdlOUAgACc2YCAAKgmAA== Date: Wed, 21 Aug 2013 04:03:05 +0000 Message-ID: <4D4FF6AB-CCC2-4ECF-B4EC-819FB2BAF98F@checkpoint.com> References: <046479A5-F6C1-4304-AA3A-C7D4056163A3@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.218] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11b5379c2aab541e0034a68652ae5ba41fd97021de Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] Resuming the cookie discussion 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, 21 Aug 2013 04:03:14 -0000 On Aug 20, 2013, at 9:01 PM, Trevor Perrin wrote: > On Tue, Aug 20, 2013 at 1:39 AM, Yoav Nir wrote: >> Hi Trevor. >>=20 >> I think (a) is definitely worth doing, but I also think that (b) can be = done along the way. >=20 > Interesting... If we were to prioritize them, I'd argue the reverse: > (b) ("Origin Cookies") strikes me as the most economical, since it > fully addresses cookie-forcing and stealing provided TLS is secure. (a) addresses the cookie-as-bearer-token issue that makes BEAST and CRIME s= omething that people write "The Internet is broken" blog posts about rather= than just a curious result that cryptographers and crypto-geeks can get ex= cited about. >> Is there some reason why (a) and (b) can't be requirements filled by a s= ingle mechanism? >=20 > That's exactly what Smart Cookies attempt - they have origin-binding, > *and* cryptographic-binding via MAC. >=20 > But I don't know whether that's the best approach. It might be easier > to push things like ChannelID and Origin Cookies separately. >=20 >=20 >> Regarding smart cookies vs channel ID: Not changing TLS is a definite ad= vantage of Smart Cookies. Reading that message again ([1]), I'm not sure wh= ether the cookie_binding is necessary, >=20 > It's necessary so the transmitted MAC doesn't become a "bearer token" > that could be re-used by anyone. But you bind the transmitted MAC to the TLS session by getting cookie_key e= xtracted from the session. So what you transmit is not a bearer token, as i= t can't be used in another session. The cookie_binding protects you against= someone stealing the cookie during set-cookie, but that's a one-time thing= , although it could be worth it. >> but I get that it protects against passing cookies. The only issue I hav= e with this >> is that it relies on extractors, and so will break at TLS proxies. While= this is good >> from a security perspective, it's a killer for deployment. I think that = Channel ID >> works in the presence of proxies, assuming the proxies are updated and m= ove >> the encrypted extension unchanged. >=20 > I assumed that both Smart Cookies and ChannelID would break at TLS > proxies until those proxies are updated to pass some information > downstream. And then would work. If Channel ID becomes part of TLS 1.3, proxies would have to be updated. No= question there. But once it is, then the new handshake records can just be= passed along by the proxy.=20 What the proxy can't do, is to make it so that the master secret on both ha= lves of the connection are the same. The proxy performs a handshake with th= e client and with the server, and then decrypts and re-encrypts everything.= So there is no way that the client and server can calculate the same value= s for cookie_binding and for cookie_key. > Since Smart Cookies don't affect the bytes-on-the-wire, whereas > ChannelID modifies the Handshake protocol, I was also assuming Smart > Cookies would be the easier change. >=20 > Is that wrong? It is an easier change, but I don't see how you can get it to work through = a proxy. Yoav From trevp@trevp.net Wed Aug 21 00:21:46 2013 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 6274B11E81D1 for ; Wed, 21 Aug 2013 00:21:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntbJpa1MkKoU for ; Wed, 21 Aug 2013 00:21:40 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id D99F711E81C0 for ; Wed, 21 Aug 2013 00:21:39 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id n12so55224wgh.24 for ; Wed, 21 Aug 2013 00:21:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ozgqh47SuWKvar/vSLqcg3DW9jNO/TJi14wQSPxCrBg=; b=m84UcmQp83NSXkQl4O/h1pVkVb887o/i9Tto0TzkdB8Y/v99wYkxQqQnnCQQhqZ1fu WhQP5Y+HjR2Bqk116S752UZR9CJV8t0FxcNLlfm5j3aEVCxHDXjYrPhISJS15JjGWYwh sQK41YwLScXVN/pzBiEcvg+Ecm2g2d/Uy5drssM7hi8jVCCEKdSUEWXrYxacSpyGk3bX x4TE6EMLShJVhRLMq9NoHKaIEl2pKFW8puyh5sELxpHupLza/pc3CX0xAs/7Lzrqel25 cp0rvsr7inGOIxUPcnsDqYiJkYrJRNqKPLPsqO4YYIEwS+a875ON5Fqf2KudJBtXRZVC Zikg== X-Gm-Message-State: ALoCoQm425A5m+e/VtWPFhxOWvTVz2b/wJaBEMPUFdiixfeROcKtZ42wjEcYHmWsZrKTCqbAPTgw MIME-Version: 1.0 X-Received: by 10.180.80.71 with SMTP id p7mr4254895wix.48.1377069698823; Wed, 21 Aug 2013 00:21:38 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Wed, 21 Aug 2013 00:21:38 -0700 (PDT) X-Originating-IP: [199.83.223.81] In-Reply-To: <4D4FF6AB-CCC2-4ECF-B4EC-819FB2BAF98F@checkpoint.com> References: <046479A5-F6C1-4304-AA3A-C7D4056163A3@checkpoint.com> <4D4FF6AB-CCC2-4ECF-B4EC-819FB2BAF98F@checkpoint.com> Date: Wed, 21 Aug 2013 00:21:38 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] Resuming the cookie discussion 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, 21 Aug 2013 07:21:46 -0000 On Tue, Aug 20, 2013 at 9:03 PM, Yoav Nir wrote: > > But you bind the transmitted MAC to the TLS session by getting cookie_key= extracted from the session. So what you transmit is not a bearer token, as= it can't be used in another session. The cookie_binding protects you again= st someone stealing the cookie during set-cookie, but that's a one-time thi= ng, although it could be worth it. I think you're reversing "cookie_key" and "cookie_binding"? It's true that the cookie_key could have been sent explicitly by the server, instead of "extracting" it from the master secret. But then we'd be transmitting auth secrets, which we're trying to avoid. > If Channel ID becomes part of TLS 1.3, proxies would have to be updated. = No question there. But once it is, then the new handshake records can just = be passed along by the proxy. > > What the proxy can't do, is to make it so that the master secret on both = halves of the connection are the same. The proxy performs a handshake with = the client and with the server, and then decrypts and re-encrypts everythin= g. So there is no way that the client and server can calculate the same val= ues for cookie_binding and for cookie_key. The "cookie_key" and "cookie_binding" values for a TLS connection can also be passed from a TLS-terminating proxy to back-end servers. Trevor From ivan.ristic@gmail.com Wed Aug 21 15:34:39 2013 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 06A6321F9223 for ; Wed, 21 Aug 2013 15:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4ISlLALMx+m for ; Wed, 21 Aug 2013 15:34:38 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 38AF921F8F24 for ; Wed, 21 Aug 2013 15:34:38 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id j17so1343519wiw.13 for ; Wed, 21 Aug 2013 15:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=GLHhCdCaxf/Mz9bAIpLQ8bDEXs1QwfIOojxp7+3wUJE=; b=e2QheSUzI/9b0XZXtl0CHu0Hio6tIQDhs6jbtsri7ketKjHudVcBJjl2b3e6p/P4Qw SWdKOZ9QzoDWnx2/J67A7GWUaQCTa3EFvgyRbP/wRM0k5KJudeqaLbRT2Z7Z0df3osSS Znbb+r27AI1sQqL7or/+4KBR53CUSVyM8MWP4Hh4Bwqhs1KLYmaJevVaenIunDON1yNx pzcYnGxjapWVbYF3a014j3yGysyqRVul/Jc2ddaz5xswmqrfhCBvRp59p15SktW8Yl+u FSJCDL4PLAxFhlEE95azyVKppYOMQdGyB17t9KVjJamBeYF0CqOotEXsU9WS3emQpU/9 SIpQ== X-Received: by 10.180.183.19 with SMTP id ei19mr18288214wic.10.1377124477252; Wed, 21 Aug 2013 15:34:37 -0700 (PDT) Received: from mac.local (46-65-86-162.zone16.bethere.co.uk. [46.65.86.162]) by mx.google.com with ESMTPSA id bt8sm12769760wib.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Aug 2013 15:34:36 -0700 (PDT) Message-ID: <5215407B.8050009@gmail.com> Date: Wed, 21 Aug 2013 23:34:35 +0100 From: =?UTF-8?B?SXZhbiBSaXN0acSH?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: websec@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [websec] HSTS extension to defend against TLS protocol rollback? 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, 21 Aug 2013 22:34:39 -0000 Pretty soon we're going to see a good chunk of the browsers support TLS 1.2, and that's great. At the same time, all browsers are vulnerable to protocol downgrade attacks, whereby an active MITM can downgrade the connection to SSL 3. Given that this is not a TLS issue (it already defends against protocol rollback), I feel that HSTS would be a good place to implement a defence. If we have an extension that specifies the maximum TLS version supported by the server, browsers can refuse to downgrade. (If the server chooses to negotiate a lower version on the first connection attempt, well, I guess that that could be acceptable.) Has this been discussed here before? P.S. In researching this topic I also came across Brian Smith having the same idea: https://bugzilla.mozilla.org/show_bug.cgi?id=450280#c21 -- Ivan From ryan-ietfhasmat@sleevi.com Wed Aug 21 16:27:01 2013 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 2226121F9AED for ; Wed, 21 Aug 2013 16:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjB1y0cCTLXT for ; Wed, 21 Aug 2013 16:26:57 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 11B8121F9034 for ; Wed, 21 Aug 2013 16:26:56 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 44FB6286059; Wed, 21 Aug 2013 16:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=HwsfF+dG86EfdDlIm+qJErXnCcQ=; b=smrOQlXe1bNRQsOop mIEex8dibtYyooBliMwl2RfOKlC+P6ePl/UKCLhjuavp+XMrS7PDgiLXuFxJ5L+N O4fjt8kDcrNV1ivoa2D8DT/OlKbjkwJPQQk4H8kzrs06xNEDsZc6D3WUnHVN6Igg mn5kY1CzBif6eFmspKp7hpHxUo= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPA id D8020286057; Wed, 21 Aug 2013 16:26:54 -0700 (PDT) Received: from 216.239.45.93 (proxying for 216.239.45.93) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 21 Aug 2013 16:26:56 -0700 Message-ID: <684e04a5d1a0fbea820a97559736fbff.squirrel@webmail.dreamhost.com> In-Reply-To: <5215407B.8050009@gmail.com> References: <5215407B.8050009@gmail.com> Date: Wed, 21 Aug 2013 16:26:56 -0700 From: "Ryan Sleevi" To: =?iso-8859-1?Q?=22Ivan_Risti=C4=87=22?= User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org Subject: Re: [websec] HSTS extension to defend against TLS protocol rollback? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 23:27:01 -0000 On Wed, August 21, 2013 3:34 pm, Ivan Risti=C4=87 wrote: > Pretty soon we're going to see a good chunk of the browsers support TL= S > 1.2, and that's great. At the same time, all browsers are vulnerable t= o > protocol downgrade attacks, whereby an active MITM can downgrade the > connection to SSL 3. > > Given that this is not a TLS issue (it already defends against protoco= l > rollback), I feel that HSTS would be a good place to implement a > defence. If we have an extension that specifies the maximum TLS versio= n > supported by the server, browsers can refuse to downgrade. (If the > server chooses to negotiate a lower version on the first connection > attempt, well, I guess that that could be acceptable.) > > Has this been discussed here before? > > P.S. In researching this topic I also came across Brian Smith having t= he > same idea: https://bugzilla.mozilla.org/show_bug.cgi?id=3D450280#c21 > > -- > Ivan > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > We've been experimenting with it in Chromium, though through the list of preloads, rather than as an HSTS directive. Perhaps unsurprisingly, it's turned out rather hard to actually get right when we turned it on for Google.com. See http://crrev.com/195335 and http://crrev.com/199185 I'm not opposed to adding it as a directive to HSTS, but I think that'd b= e as a first step - our hope would be able to use more heuristics to protec= t even non-HSTS sites. Yngve had previously proposed a variety of checks for that in the past that we've definitely thought are reasonable. It would be great to be abl= e to deploy. I'd like to slowly see us on the browser side begin to move to a whitelis= t for SSL3 fallback, rather than the current policies. If browser's bear that inertia cost and evangelism problem, is it still as significant an issue for HSTS (as opposed to having non-browser applications simply disabling/removing fallback, because the browsers no longer do it). From yngve@spec-work.net Wed Aug 21 17:12:15 2013 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 B49D611E80EA for ; Wed, 21 Aug 2013 17:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCniPzJejgMB for ; Wed, 21 Aug 2013 17:12:11 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 44E6D11E8134 for ; Wed, 21 Aug 2013 17:12:10 -0700 (PDT) Received: from 159.168.202.84.customer.cdi.no ([84.202.168.159]:57581 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1VCIVU-0006wI-RW for websec@ietf.org; Thu, 22 Aug 2013 02:12:08 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: websec@ietf.org References: <5215407B.8050009@gmail.com> Date: Thu, 22 Aug 2013 02:11:48 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <5215407B.8050009@gmail.com> User-Agent: Opera Mail/12.15 (Win32) Subject: Re: [websec] HSTS extension to defend against TLS protocol rollback? 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, 22 Aug 2013 00:12:15 -0000 Hi Ivan, On Thu, 22 Aug 2013 00:34:35 +0200, Ivan Risti=C4=87 = wrote: > Pretty soon we're going to see a good chunk of the browsers support TL= S > 1.2, and that's great. At the same time, all browsers are vulnerable t= o > protocol downgrade attacks, whereby an active MITM can downgrade the > connection to SSL 3. > > Given that this is not a TLS issue (it already defends against protoco= l > rollback), I feel that HSTS would be a good place to implement a > defence. If we have an extension that specifies the maximum TLS versio= n > supported by the server, browsers can refuse to downgrade. (If the > server chooses to negotiate a lower version on the first connection > attempt, well, I guess that that could be acceptable.) > > Has this been discussed here before? > > P.S. In researching this topic I also came across Brian Smith having t= he > same idea: https://bugzilla.mozilla.org/show_bug.cgi?id=3D450280#c21 This have been discussed a couple of times in the TLS WG group the past = = couple of years, and was discussed at the TLS WG's IETF 84 meeting in = Vancouver a year ago. In those discussions there were two groups of proposals: 1) A couple of variations from EKR and Adam Langley using Special Cipher= = Suite signaling (SCSV) to indicate the client's maximum supported versio= n = so that the server could know the client was being downgraded for some = reason, and 2) my proposal to use the server's ability to respond with the RFC 5746 = = Renego extension as a proxy indication that the server is (or ought to b= e) = able to tolerate a client signaling a newer TLS version than supported b= y = the server, and force a new handshake signaling the highest supported = version if a fallback is occurring. This approach is deployed in Opera = versions 10.50 to 11.0x and 12.x (not v15+) As the discussion is being reopened, I have just refreshed my draft = = . I have not updated the statistics, since I do not yet have recent = statistics that can be used. Regarding your proposal I think it may rely too heavily on the server = administrator actively enabling this extension. While the extension coul= d = be added automatically, it might depend on the server either being the T= LS = server too, or automatically aware of the front-end's version, or the = front-end will have to add the extension while it is forwarding the HTTP= = response (and in that case there might be additional issues related to = variations of HTTP, such as SPDY). Additionally, I think a longterm problem would be how to determine when = to = finally disable the client support for rollbacks? I think the goal shoul= d = be to remove version rollback as a client option. Regarding your short description of how it would work, I'll also note th= at = the client would not be able to see the HSTS header before it have = actually sent a HTTP request to the server (IOW, similar to the = pre-existing HSTS bootstrap problem), and in the case of a rollback = attack that will be *after* the attacker have managed to force the clien= t = to roll back to an older version. This would then mean that the attacker= = is (supposedly) able to decrypt (or otherwise compromise) the informatio= n = sent in that request (cookies, login credentials, credit card info, etc.= ). = Once the client have received the HSTS header it will then have to close= = the connection, reconnect and negotiate using its highest version withou= t = allowing rollbacks, and perhaps resubmit the request (which have various= = problems concerning requests that have side effects, e.g. purchase = actions). This approach would probably work against attackers that are using attac= ks = of the kind used in BEAST or CRIME if newer protocol versions have been = = patched against the particular attack being deployed. I am also not sure if it is such a good idea to migrate detailed transpo= rt = layer information (version support) into a higher level protocol (HTTP).= -- = Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From tobias.gondrom@gondrom.org Mon Aug 26 15:22:34 2013 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 7B03B11E822B for ; Mon, 26 Aug 2013 15:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.35 X-Spam-Level: X-Spam-Status: No, score=-95.35 tagged_above=-999 required=5 tests=[AWL=0.012, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsIdPEJjBLVu for ; Mon, 26 Aug 2013 15:22:30 -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 A8CE911E8210 for ; Mon, 26 Aug 2013 15:22:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=mDWSulZmmDMArB5cergcqy2QUhEwedLb3zaAXgg20ugjDIXDH1yLb2SiCzihglnyhA8FcTmdYUzMpaBh9z1EMjw09adYpnXS7wBZ4OTS/II61YQ8tLgMma+5XQgSmJVe; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 28144 invoked from network); 27 Aug 2013 00:22:20 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.100?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 27 Aug 2013 00:22:20 +0200 Message-ID: <521BD51C.2090601@gondrom.org> Date: Mon, 26 Aug 2013 23:22:20 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: ryan-ietfhasmat@sleevi.com References: <5215407B.8050009@gmail.com> <684e04a5d1a0fbea820a97559736fbff.squirrel@webmail.dreamhost.com> In-Reply-To: <684e04a5d1a0fbea820a97559736fbff.squirrel@webmail.dreamhost.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: websec@ietf.org Subject: Re: [websec] HSTS extension to defend against TLS protocol rollback? 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, 26 Aug 2013 22:22:34 -0000 Hi, On 22/08/13 00:26, Ryan Sleevi wrote: > On Wed, August 21, 2013 3:34 pm, Ivan Ristić wrote: >> Pretty soon we're going to see a good chunk of the browsers support TLS >> 1.2, and that's great. At the same time, all browsers are vulnerable to >> protocol downgrade attacks, whereby an active MITM can downgrade the >> connection to SSL 3. >> >> Given that this is not a TLS issue (it already defends against protocol >> rollback), I feel that HSTS would be a good place to implement a >> defence. If we have an extension that specifies the maximum TLS version >> supported by the server, browsers can refuse to downgrade. (If the >> server chooses to negotiate a lower version on the first connection >> attempt, well, I guess that that could be acceptable.) >> >> Has this been discussed here before? >> >> P.S. In researching this topic I also came across Brian Smith having the >> same idea: https://bugzilla.mozilla.org/show_bug.cgi?id=450280#c21 >> >> -- >> Ivan >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >> > We've been experimenting with it in Chromium, though through the list of > preloads, rather than as an HSTS directive. Perhaps unsurprisingly, it's > turned out rather hard to actually get right when we turned it on for > Google.com. See http://crrev.com/195335 and http://crrev.com/199185 > > I'm not opposed to adding it as a directive to HSTS, but I think that'd be > as a first step - our hope would be able to use more heuristics to protect > even non-HSTS sites. I tend to agree. Can see the use case for HSTS. But on the other hand also see that you potentially might want this capability also in non-HSTS environments. Which would suggest an orthogonal approach? Tobias > Yngve had previously proposed a variety of checks for that in the past > that we've definitely thought are reasonable. It would be great to be able > to deploy. > > I'd like to slowly see us on the browser side begin to move to a whitelist > for SSL3 fallback, rather than the current policies. If browser's bear > that inertia cost and evangelism problem, is it still as significant an > issue for HSTS (as opposed to having non-browser applications simply > disabling/removing fallback, because the browsers no longer do it). > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From tobias.gondrom@gondrom.org Mon Aug 26 15:27:12 2013 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 B4FD311E823E for ; Mon, 26 Aug 2013 15:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.35 X-Spam-Level: X-Spam-Status: No, score=-95.35 tagged_above=-999 required=5 tests=[AWL=0.012, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBJLvdxmzfFM for ; Mon, 26 Aug 2013 15:27:08 -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 8199E11E8237 for ; Mon, 26 Aug 2013 15:27:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=fvUBDWeneb2stu1aB2wjlEypIKs0Yi//aytRzGdGUXDIsJN46OT+3bNZ/I9zNDcX91m5JARlBn9zkXozN2c2JCR4YquKDCwZcpthbRkMApDLEeES88ZPSnWESH14nQjk; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 28203 invoked from network); 27 Aug 2013 00:27:01 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.100?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 27 Aug 2013 00:27:01 +0200 Message-ID: <521BD634.4070700@gondrom.org> Date: Mon, 26 Aug 2013 23:27:00 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: trevp@trevp.net References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] Resuming the cookie discussion 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, 26 Aug 2013 22:27:13 -0000 My feeling is that both (a) and (b) would be worth doing. Though not sure on the best approach yet. Best regards, Tobias On 20/08/13 01:44, Trevor Perrin wrote: > To pick this up again, it would be great to have: > > (a) Some cryptographic binding for cookies, either using asymmetric > crypto (ChannelID) or symmetric (Smart Cookies), to prevent them being > useable when transferred between browsers. > > (b) Some origin-binding for cookies to prevent them leaking to > subdomains and being forced by other domains (Origin Cookies). > > > Both (a) and (b) address the threats of cookie-forcing and > cookie-stealing, but neither is a complete replacement for the other: > > (a) Cryptographic binding of cookies would not prevent an attacker > who controls related domains from: > - deleting cookies > - stealing a cookie from user A and then forcing it back to A, > later, to roll-back the cookie to an earlier value > > (b) Origin binding of cookies would not protect against a failure in > TLS confidentiality that exposes the cookie's value. > > > Questions > ========= > * Are both (a) and (b) worth doing? Should we prioritize one? > > * Regarding ChannelID vs Smart Cookies: ChannelID provides a > "bindable" identifier that could be used for other things besides > cookies (OAuth tokens? other?). But it also requires TLS changes and > an additional signing operation on the client. The Smart Cookie > approach is more efficient but also narrowly scoped to cookies. > > Do people have other arguments, or strong feelings, one way or the other? > > > Trevor > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From internet-drafts@ietf.org Mon Aug 26 16:48:16 2013 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 82CFC11E8261; Mon, 26 Aug 2013 16:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Zoz1SpQzL+t; Mon, 26 Aug 2013 16:48:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9C111E8106; Mon, 26 Aug 2013 16:48:15 -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.70.p1 Message-ID: <20130826234815.1709.45571.idtracker@ietfa.amsl.com> Date: Mon, 26 Aug 2013 16:48:15 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-x-frame-options-11.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: Mon, 26 Aug 2013 23:48:16 -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 Header Field X-Frame-Options Author(s) : David Ross Tobias Gondrom Filename : draft-ietf-websec-x-frame-options-11.txt Pages : 13 Date : 2013-08-26 Abstract: To improve the protection of web applications against Clickjacking, this definition describes the X-Frame-Options HTTP response header field that declares a policy communicated from the server to the client browser on whether the browser may display the transmitted content in frames that are part of other web pages. This informational document serves to document the existing use and specification of this X-Frame-Options HTTP response header field. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-x-frame-options-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Aug 26 16:48:16 2013 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 DFCF511E8259 for ; Mon, 26 Aug 2013 16:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ejq2qc3PFUaO; Mon, 26 Aug 2013 16:48:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10ECD11E8108; Mon, 26 Aug 2013 16:48:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: websec-chairs@tools.ietf.org, draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, barryleiba@computer.org, rlb@ipv.sx X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130826234816.1709.21636.idtracker@ietfa.amsl.com> Date: Mon, 26 Aug 2013 16:48:16 -0700 Subject: [websec] New Version Notification - draft-ietf-websec-x-frame-options-11.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: Mon, 26 Aug 2013 23:48:17 -0000 A new version (-11) has been submitted for draft-ietf-websec-x-frame-option= s: http://www.ietf.org/internet-drafts/draft-ietf-websec-x-frame-options-11.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-x-frame-options-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From internet-drafts@ietf.org Tue Aug 27 07:20:37 2013 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 3E01811E834E; Tue, 27 Aug 2013 07:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgJXq0OTt-eo; Tue, 27 Aug 2013 07:20:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9EC11E8345; Tue, 27 Aug 2013 07:20:36 -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.70.p1 Message-ID: <20130827142036.18330.8857.idtracker@ietfa.amsl.com> Date: Tue, 27 Aug 2013 07:20:36 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-x-frame-options-12.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: Tue, 27 Aug 2013 14:20:37 -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 Header Field X-Frame-Options Author(s) : David Ross Tobias Gondrom Filename : draft-ietf-websec-x-frame-options-12.txt Pages : 13 Date : 2013-08-27 Abstract: To improve the protection of web applications against Clickjacking, this definition describes the X-Frame-Options HTTP response header field that declares a policy communicated from the server to the client browser on whether the browser may display the transmitted content in frames that are part of other web pages. This informational document serves to document the existing use and specification of this X-Frame-Options HTTP response header field. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-x-frame-options-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Aug 27 07:20:37 2013 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 8F2BE11E834B for ; Tue, 27 Aug 2013 07:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HqNSGHh5qfW; Tue, 27 Aug 2013 07:20:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D38DE11E8196; Tue, 27 Aug 2013 07:20:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: websec-chairs@tools.ietf.org, draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130827142036.18330.36116.idtracker@ietfa.amsl.com> Date: Tue, 27 Aug 2013 07:20:36 -0700 Subject: [websec] New Version Notification - draft-ietf-websec-x-frame-options-12.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: Tue, 27 Aug 2013 14:20:37 -0000 A new version (-12) has been submitted for draft-ietf-websec-x-frame-option= s: http://www.ietf.org/internet-drafts/draft-ietf-websec-x-frame-options-12.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-x-frame-options-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From ietf-secretariat-reply@ietf.org Tue Aug 27 20:33:03 2013 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 4AF2321F9CBF for ; Tue, 27 Aug 2013 20:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.446 X-Spam-Level: X-Spam-Status: No, score=-101.446 tagged_above=-999 required=5 tests=[AWL=-1.065, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIwbZHuUGo6x; Tue, 27 Aug 2013 20:33:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F1C21F9CC3; Tue, 27 Aug 2013 20:33:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: websec-chairs@tools.ietf.org, draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130828033302.28958.47014.idtracker@ietfa.amsl.com> Date: Tue, 27 Aug 2013 20:33:02 -0700 From: IETF Secretariat X-Mailman-Approved-At: Wed, 28 Aug 2013 00:45:57 -0700 Subject: [websec] ID Tracker State Update Notice: 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, 28 Aug 2013 03:33:03 -0000 State changed to Approved-announcement to be sent from IESG Evaluation::AD = Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-o= ptions/ From iesg-secretary@ietf.org Wed Aug 28 06:11:44 2013 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 3E2DE11E818A; Wed, 28 Aug 2013 06:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zg5eEo+akYSG; Wed, 28 Aug 2013 06:11:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD0011E81B0; Wed, 28 Aug 2013 06:11:42 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130828131142.9621.2653.idtracker@ietfa.amsl.com> Date: Wed, 28 Aug 2013 06:11:42 -0700 Cc: websec mailing list , websec chair , RFC Editor Subject: [websec] Document Action: 'HTTP Header Field X-Frame-Options' to Informational RFC (draft-ietf-websec-x-frame-options-12.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: Wed, 28 Aug 2013 13:11:44 -0000 The IESG has approved the following document: - 'HTTP Header Field X-Frame-Options' (draft-ietf-websec-x-frame-options-12.txt) as Informational RFC This document is the product of the Web Security Working Group. The IESG contact persons are Barry Leiba and Pete Resnick. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ Technical Summary This informational document serves to document the existing use and specification of the X-Frame-Options HTTP response header field. To improve the protection of web applications against Clickjacking, this definition describes the X-Frame-Options HTTP response header field that declares a policy communicated from the server to the client browser on whether the browser may display the transmitted content in frames that are part of other web pages. Review and Consensus In 2009 and 2010 many browser vendors introduced the use of a non- standard HTTP header field "X-Frame-Options" to protect against Clickjacking. There have been differences between the various implementations which may cause security and interoperability concerns. This draft has been produced as informational by the websec working group to document the current use and also to function as a baseline for the future unified standard as part of the currently produced Content Security Policy 1.1 (by WebAppSec at the W3C) - and to get rid of the deprecated "X-" (see RFC6648). The review process took sufficient time and involved a medium amount of people with deep browser security knowledge. During the review process no major controversies came up, which is not too surprising as the draft is intended as informational and documenting. Personnel Yoav Nir is the Document Shepherd. Barry Leiba is the Responsible Area Director. From ynir@checkpoint.com Wed Aug 28 06:19:29 2013 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 2FF3F21F90CC for ; Wed, 28 Aug 2013 06:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.643 X-Spam-Level: X-Spam-Status: No, score=-10.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvcBGdo5pq1U for ; Wed, 28 Aug 2013 06:19:24 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 25ACB21F90A7 for ; Wed, 28 Aug 2013 06:19:23 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7SDJMF1014101 for ; Wed, 28 Aug 2013 16:19:22 +0300 X-CheckPoint: {521DF8DA-8-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Wed, 28 Aug 2013 16:19:22 +0300 From: Yoav Nir To: websec mailing list Thread-Topic: Document Action: 'HTTP Header Field X-Frame-Options' to Informational RFC (draft-ietf-websec-x-frame-options-12.txt) Thread-Index: AQHOo/AuFmyVdfeG2kaGO5wouz4uTpmqaEOA Date: Wed, 28 Aug 2013 13:19:22 +0000 Message-ID: <9ABB97BC-881D-4D43-B0EE-04954B6994F3@checkpoint.com> References: <20130828131142.9621.2653.idtracker@ietfa.amsl.com> In-Reply-To: <20130828131142.9621.2653.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.24.31] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] Document Action: 'HTTP Header Field X-Frame-Options' to Informational RFC (draft-ietf-websec-x-frame-options-12.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: Wed, 28 Aug 2013 13:19:29 -0000 Congratulations. Thanks to all who participated in the discussion, and special thanks to the= document authors who took on this onerous (especially in the last two week= s) task.=20 Yoav On Aug 28, 2013, at 4:11 PM, The IESG wrote: > The IESG has approved the following document: > - 'HTTP Header Field X-Frame-Options' > (draft-ietf-websec-x-frame-options-12.txt) as Informational RFC >=20 > This document is the product of the Web Security Working Group. >=20 > The IESG contact persons are Barry Leiba and Pete Resnick. >=20 > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/ >=20 >=20 >=20 >=20 > Technical Summary >=20 > This informational document serves to document the existing use and=20 > specification of the X-Frame-Options HTTP response header field. >=20 > To improve the protection of web applications against Clickjacking, > this definition describes the X-Frame-Options HTTP response header > field that declares a policy communicated from the server to the > client browser on whether the browser may display the transmitted > content in frames that are part of other web pages. >=20 > Review and Consensus >=20 > In 2009 and 2010 many browser vendors introduced the use of a non- > standard HTTP header field "X-Frame-Options" to protect against=20 > Clickjacking. There have been differences between the various=20 > implementations which may cause security and interoperability=20 > concerns. This draft has been produced as informational by the websec=20 > working group to document the current use and also to function as a=20 > baseline for the future unified standard as part of the currently=20 > produced Content Security Policy 1.1 (by WebAppSec at the W3C) - and=20 > to get rid of the deprecated "X-" (see RFC6648).=20 >=20 > The review process took sufficient time and involved a medium amount=20 > of people with deep browser security knowledge. During the review=20 > process no major controversies came up, which is not too surprising=20 > as the draft is intended as informational and documenting. >=20 >=20 > Personnel >=20 > Yoav Nir is the Document Shepherd. Barry Leiba is the Responsible=20 > Area Director. From tobias.gondrom@gondrom.org Wed Aug 28 09:18:14 2013 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 2357221F960E for ; Wed, 28 Aug 2013 09:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.35 X-Spam-Level: X-Spam-Status: No, score=-95.35 tagged_above=-999 required=5 tests=[AWL=0.011, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUroddYxhvs2 for ; Wed, 28 Aug 2013 09:18:09 -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 53EB511E81FE for ; Wed, 28 Aug 2013 09:18:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=IidWfhhI7TMHYdhd1/FzaJd1KTG6vG1/FdBpNYSnsoqsdp6WyNanrOy0EZM+YJVJ5QHP/YEmUM5OWaMBhdbU+3Pd8L4hxZtDifEoYNwPSm9hEUuNNUtpto6VV6Ny6bhw; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type; Received: (qmail 26399 invoked from network); 28 Aug 2013 18:18:01 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.100?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 28 Aug 2013 18:18:01 +0200 Message-ID: <521E22B9.6050809@gondrom.org> Date: Wed, 28 Aug 2013 17:18:01 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: websec@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------090406080903090105040009" Subject: [websec] minutes for WEBSEC meeting in Berlin 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, 28 Aug 2013 16:18:14 -0000 This is a multi-part message in MIME format. --------------090406080903090105040009 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello dear Websec fellows, FYI: we just uploaded our meeting minutes. You can find them here: http://www.ietf.org/proceedings/87/minutes/minutes-87-websec Please contact me or Yoav directly in case of any corrections/comments on the minutes before Sep-10. Tobias & Yoav chairs of websec Ps.: of course all presentation slides and agenda are online as well: https://datatracker.ietf.org/meeting/87/materials.html#websec --------------090406080903090105040009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello dear Websec fellows,

FYI: we just uploaded our meeting minutes. You can find them here:
http://www.ietf.org/proceedings/87/minutes/minutes-87-websec

Please contact me or Yoav directly in case of any corrections/comments on the minutes before Sep-10.

Tobias & Yoav
chairs of websec


Ps.: of course all presentation slides and agenda are online as well:
https://datatracker.ietf.org/meeting/87/materials.html#websec

 --------------090406080903090105040009-- From ynir@checkpoint.com Wed Aug 28 20:53:53 2013 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 03E1621F9E3A for ; Wed, 28 Aug 2013 20:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.642 X-Spam-Level: X-Spam-Status: No, score=-10.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzFGbsG9McuP for ; Wed, 28 Aug 2013 20:53:46 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 29FCA21F9E3B for ; Wed, 28 Aug 2013 20:53:42 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7T3rfKr021189 for ; Thu, 29 Aug 2013 06:53:41 +0300 X-CheckPoint: {521EC5C5-4-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Thu, 29 Aug 2013 06:53:39 +0300 From: Yoav Nir To: IETF WebSec WG Thread-Topic: HPKP: Calling consensus on #58 and #60 Thread-Index: AQHOpGtX3ceqgILDmUS84eCDn4g8hA== Date: Thu, 29 Aug 2013 03:53:40 +0000 Message-ID: <091C57D1-1DBD-4078-9EF6-BBFD4379C63E@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.159] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [websec] HPKP: Calling consensus on #58 and #60 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, 29 Aug 2013 03:53:53 -0000 Hi all In recent weeks we've had quite a lively discussion on both issues. Going o= ver those threads, I think the inevitable conclusion is that there is not c= onsensus in the group to make any of these proposed changes, and in fact th= ere is rough consensus to defer making those changes to a future revision o= f the protocol. The CA names idea (#58) was met with a lot of enthusiasm in the group, and = indeed, what's not to like? 'pin-name=3D"Certigna"' is much easier to confi= gure than 'pin-sha1=3D"4n972HfV354KP560yw4uqe/baXc=3D"'. But after much dis= cussion, it turned out that there were a lot of gotchas. Names change, mean= ings change, human readable strings need to be kept in sync with machine re= adable hashes. Both UAs and human administrators have to be made aware of c= hanges to names and equivalent hashes, and they both need a policy on what = to do if they cannot update. We don't currently have the infrastructure to = make this reliable. So we'll go with Gervase's suggestion ([1]) and define = the syntax so that future pin formats can be added, and close this issue. The well-known URI idea (#60) also looked cool. No data going to non-suppor= ting UAs, and those only reading the data once per session, rather than wit= h every request, reducing header bloat. It works for favicon, why not for P= KP? And I agree with Mark, that if we do it in headers now, we'll never mov= e it to the well-known resource. However, people who do have implementation= s dismissed the argument about header bloat ([2]), and were worried timing = issues with when to fetch the resource, and how long it needs to be cached,= etc. I do think we should take the suggestion to treat a missing header as= a no-op rather than as something that nullifies pinning. This can allow si= tes to reduce header bloat by sending the HPKP header only seldom, although= with proxies, this is no guarantee of success either. It should be noted t= hat the current spec of HTTP/2 solves the header bloat issue, by having the= header only on the first request in the connection. Tobias & Yoav [1] http://www.ietf.org/mail-archive/web/websec/current/msg01851.html [2] http://www.ietf.org/mail-archive/web/websec/current/msg01772.html From ivan.ristic@gmail.com Fri Aug 30 02:26:18 2013 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 310F321E8064 for ; Fri, 30 Aug 2013 02:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtfFnXbMKpK1 for ; Fri, 30 Aug 2013 02:26:17 -0700 (PDT) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 208E121F9F31 for ; Fri, 30 Aug 2013 02:26:07 -0700 (PDT) Received: by mail-bk0-f51.google.com with SMTP id mx10so574683bkb.38 for ; Fri, 30 Aug 2013 02:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ILQ+seH8RvzdlyiTbHGbNdl/BAVXDDsGNar1eSz19Rw=; b=F0OH0sysSoR82esT9AELk5KFRtz38aD3L176VYjMlal/FxAPpYUDbDiI8RTIYLK7R/ lJ2ayD3zSUpB21v8ga1BLFHBZ+zWHUKhHoVKQjdBJtOPvso0sOuhPuZbVkNr5oxg0+sq 4mAUIuaFWJlqI7W70d/Vmg+NSMS/c9JtNWnp5VosNcXNG2g3JpfldSFzK/voeVJ1inzR LO8T1uB2pWp50zlPp8DWPDo5x6zHVgAliekSKpO9CVawFsCvmJaQ1kqiX0eRWTaoUIW0 fhEYy/4grEqiEaW/FW1ednPGmmHbF9RSM4rbUlAb4cbI4aJ3kdSkBYKSwPvpHSS9B7xM xOkA== X-Received: by 10.205.22.138 with SMTP id qw10mr895133bkb.29.1377854767136; Fri, 30 Aug 2013 02:26:07 -0700 (PDT) Received: from [192.168.0.98] (46-65-86-162.zone16.bethere.co.uk. [46.65.86.162]) by mx.google.com with ESMTPSA id no2sm8046097bkb.15.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 02:26:06 -0700 (PDT) Message-ID: <5220652E.9080806@gmail.com> Date: Fri, 30 Aug 2013 10:26:06 +0100 From: =?UTF-8?B?SXZhbiBSaXN0acSH?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: websec@ietf.org References: <5215407B.8050009@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [websec] HSTS extension to defend against TLS protocol rollback? 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, 30 Aug 2013 09:26:18 -0000 On 22/08/2013 01:11, Yngve N. Pettersen wrote: > Hi Ivan, Hi Yngve, Thank you for providing so much material. (Yngve also emailed me directly with further information.) It took me some time to go through all of it. > On Thu, 22 Aug 2013 00:34:35 +0200, Ivan Ristić > wrote: > >> Pretty soon we're going to see a good chunk of the browsers support TLS >> 1.2, and that's great. At the same time, all browsers are vulnerable to >> protocol downgrade attacks, whereby an active MITM can downgrade the >> connection to SSL 3. >> >> Given that this is not a TLS issue (it already defends against protocol >> rollback), I feel that HSTS would be a good place to implement a >> defence. If we have an extension that specifies the maximum TLS version >> supported by the server, browsers can refuse to downgrade. (If the >> server chooses to negotiate a lower version on the first connection >> attempt, well, I guess that that could be acceptable.) >> >> Has this been discussed here before? >> >> P.S. In researching this topic I also came across Brian Smith having the >> same idea: https://bugzilla.mozilla.org/show_bug.cgi?id=450280#c21 > > This have been discussed a couple of times in the TLS WG group the past > couple of years, and was discussed at the TLS WG's IETF 84 meeting in > Vancouver a year ago. For those interested, here are some useful links: http://my.opera.com/yngve/blog/2012/11/02/standards-work-update https://www.ietf.org/mail-archive/web/tls/current/msg08099.html http://www.ietf.org/mail-archive/web/tls/current/msg08861.html > In those discussions there were two groups of proposals: > > 1) A couple of variations from EKR and Adam Langley using Special Cipher > Suite signaling (SCSV) to indicate the client's maximum supported > version so that the server could know the client was being downgraded > for some reason, and > > 2) my proposal to use the server's ability to respond with the RFC 5746 > Renego extension as a proxy indication that the server is (or ought to > be) able to tolerate a client signaling a newer TLS version than > supported by the server, and force a new handshake signaling the highest > supported version if a fallback is occurring. This approach is deployed > in Opera versions 10.50 to 11.0x and 12.x (not v15+) > > As the discussion is being reopened, I have just refreshed my draft > > . I have not updated the statistics, since I do not yet have recent > statistics that can be used. > > Regarding your proposal I think it may rely too heavily on the server > administrator actively enabling this extension. While the extension > could be added automatically, it might depend on the server either being > the TLS server too, or automatically aware of the front-end's version, > or the front-end will have to add the extension while it is forwarding > the HTTP response (and in that case there might be additional issues > related to variations of HTTP, such as SPDY). > > Additionally, I think a longterm problem would be how to determine when > to finally disable the client support for rollbacks? I think the goal > should be to remove version rollback as a client option. > > Regarding your short description of how it would work, I'll also note > that the client would not be able to see the HSTS header before it have > actually sent a HTTP request to the server (IOW, similar to the > pre-existing HSTS bootstrap problem), and in the case of a rollback > attack that will be *after* the attacker have managed to force the > client to roll back to an older version. This would then mean that the > attacker is (supposedly) able to decrypt (or otherwise compromise) the > information sent in that request (cookies, login credentials, credit > card info, etc.). Once the client have received the HSTS header it will > then have to close the connection, reconnect and negotiate using its > highest version without allowing rollbacks, and perhaps resubmit the > request (which have various problems concerning requests that have side > effects, e.g. purchase actions). > > This approach would probably work against attackers that are using > attacks of the kind used in BEAST or CRIME if newer protocol versions > have been patched against the particular attack being deployed. > > I am also not sure if it is such a good idea to migrate detailed > transport layer information (version support) into a higher level > protocol (HTTP). I think this one is tricky. Browsers could fix the problem quickly, by dropping voluntary rollback, because it's not specified by the protocol anyway. But they clearly don't want (yet) to do it, because of the potential interoperability problems. Personally, I share your views that this should be addressed in the TLS protocol, initially by adopting your proposal, but also later by adding an explicit mechanism to communicate highest supported protocol versions, by both the server and the client. But even with your proposal there will be false positives, and the key question is whether the browsers want to go there. Going the HSTS route side-steps the problem with the false positives, and enables those who care about their security to close a substantial hole in their armour. For such people, there is no significant additional burden, because HSTS is basically mandatory for robust security. (As a side note, perhaps specifying the highest supporting version in HSTS is not necessary. Disabling rollback might be sufficient.) Sure, it's a band-aid, but that's what HSTS is. -- Ivan