From ryan-ietfhasmat@sleevi.com Mon Mar 4 16:56: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 9C1A121F88AC for ; Mon, 4 Mar 2013 16:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 SG8B0q+Fab+Y for ; Mon, 4 Mar 2013 16:56:25 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id EE40821F8891 for ; Mon, 4 Mar 2013 16:56:24 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id A0033428075 for ; Mon, 4 Mar 2013 16:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :date:subject:from:to:reply-to:mime-version:content-type: content-transfer-encoding; s=sleevi.com; bh=SOh1EgdCg1Kn13lV8mo+ OrXk0DY=; b=tP9aszglkVLFfJdOwIUf4/2MGZzM20TskLEpnVYDVPtcIq3wqUa3 ANiQRHZw49ZYQ70Jmlux6XzZn6JJctmIRivFOpKVIj3L+J3pPCUpONVrOcQpW0vB 39V8vrvSdWyL4CFYnP7wXl4VQF+uSCCpc4Xm4BlKokFflma3rv3drwc= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPA id 8308242806E for ; Mon, 4 Mar 2013 16:56:24 -0800 (PST) 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, 4 Mar 2013 16:56:24 -0800 Message-ID: Date: Mon, 4 Mar 2013 16:56:24 -0800 From: "Ryan Sleevi" To: websec@ietf.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [websec] Issue 52 - Key pinning draft should clarify max-age as required 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, 05 Mar 2013 00:56:25 -0000 This was one of the outstanding issues from draft-03, raised in http://trac.tools.ietf.org/wg/websec/trac/ticket/52 The Chrises and I believe this has been addressed sufficiently in draft-04, through the clarifications in http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1.1= and http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.3.1 Are there any objections to closing this out? From ryan-ietfhasmat@sleevi.com Mon Mar 4 16:57: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 91F3921F88B6 for ; Mon, 4 Mar 2013 16:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 6in+POHYQZT1 for ; Mon, 4 Mar 2013 16:57:21 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2A23121F88A0 for ; Mon, 4 Mar 2013 16:57:21 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id E38F8BC04C for ; Mon, 4 Mar 2013 16:57:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :date:subject:from:to:reply-to:mime-version:content-type: content-transfer-encoding; s=sleevi.com; bh=5BKJjNeQU2vxPm4dAoss RfnH04M=; b=bYeTTfx8nkeJeYtHNNqwbNhWS05EBrbUBbn61skAC6sa0bXaIx8n 6Q2UKJzyPKyU8kTqT9miMFAGY19mKq38BINn5+/hQeAQYCTHM/3PjfxNlnCZq11W EUxtW/uylEa4bR+PPzW8yfDbFI6bA21kL6tuD8+VQVGtiP6HeTwygsk= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPA id DFD9DBC047 for ; Mon, 4 Mar 2013 16:57:20 -0800 (PST) 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, 4 Mar 2013 16:57:20 -0800 Message-ID: <77ade868e5042a347751a9d025b84b19.squirrel@webmail.dreamhost.com> Date: Mon, 4 Mar 2013 16:57:20 -0800 From: "Ryan Sleevi" To: websec@ietf.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [websec] Issue 53 - Key pinning should clarify status of pin validation with private trust anchors 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, 05 Mar 2013 00:57:21 -0000 This was raised during our discussions in Atlanta, and continued on the mailing list under http://trac.tools.ietf.org/wg/websec/trac/ticket/53 As discussed during Atlanta, the way that pinning is currently implemente= d within Google Chrome, pinning is only enforced as it relates to so-called "public trust anchors" (eg: those shipped by default as part of a browser or OS installation, not those installed by a user). The motivation for this was and is simple: If you have sufficient local privilege to install additional trust anchors on a device, then it's presumed you have sufficient privilege to take any number of other actions, including disabling pinning enforcement entirely. As such, havin= g the UA disable enforcement selectively is strictly less worse, from a security perspective, than having the UA disable enforcement entirely, an= d still provides significant benefit through the reduction of risk through public trust anchors. However, this creates an interesting split between the specification language and implementations. In draft-04, we've tried to clarify this through the text in Section 2.6, http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.6 , along with the addition of a "strict" mode, as described in Section 2.1.4= , http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1.4 While there is an open question as to whether or not such user-agent behaviour is appropriate to specify here, does the group feel the propose= d text sufficiently addresses the issue as originally raised? From ryan-ietfhasmat@sleevi.com Mon Mar 4 16:58: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 7213921F88E2 for ; Mon, 4 Mar 2013 16:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 QddmINvZMG3r for ; Mon, 4 Mar 2013 16:58:05 -0800 (PST) Received: from homiemail-a65.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id C019221F88A0 for ; Mon, 4 Mar 2013 16:57:57 -0800 (PST) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id E91957E405D for ; Mon, 4 Mar 2013 16:57:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :date:subject:from:to:reply-to:mime-version:content-type: content-transfer-encoding; s=sleevi.com; bh=+4YD0RWcYH5CS9xm+5kN EeKJUnc=; b=ibRoQ+/fBihugHXd7jamdPcW+tvwLBFl3xr7FczNN3447Zs4Ns8i Hdf/oa0400uTd8+LUcvHLuM2jkuXP38BB2M8y71f7Zc83+N5zr/AygBUp6gmQs+K JvQwNwMqJ+WUNAU48R1poph3sMbixTph+x01p/eSg5R3E7on6eFVPew= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPA id E64EF7E4058 for ; Mon, 4 Mar 2013 16:57:56 -0800 (PST) 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, 4 Mar 2013 16:57:56 -0800 Message-ID: Date: Mon, 4 Mar 2013 16:57:56 -0800 From: "Ryan Sleevi" To: websec@ietf.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [websec] Issue 55 - Key pinning should clarify that the newest pinning information takes precedence 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, 05 Mar 2013 00:58:05 -0000 This was raised with http://trac.tools.ietf.org/wg/websec/trac/ticket/55 = , as a concern about the interaction between static/preloaded pin entries and those that were noted later (eg: through the observation of the header) In draft-04, Section 2.7 http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.7 addresses this by indicating that UAs MUST use the newest information available. Note: This does not normatively describe how a UA must determine newest. The assumption here is that this represents the "newest observed", but th= e question is whether or not that should be explicitly specified. For example, imagine a UA that supports automatic updates to Preloaded Pi= n Lists. One interpretation of "newest information" would be to look at the most recent update to the preloaded pin list as a whole. Another interpretation of "newest information" may be to look at the date/time that the entry was originally added/updated in the "preloaded pin list". Imagine this UA had a preload for Site 1 to a set of pins, with the preload created at T=3D0. Later, at T=3D5, it observes a Max-Age of 0, effectively unpinning the host. At T=3D10, the UA vendor ships a new upda= te to the preloaded pin list that adds Site 2, but which has not been update= d to unpin Site 1. Under the first interpretation of "newest information", Site 1 would be "reactivated", by virtue of observing an update to the preloaded pin list= . Under the second interpretation, Site 1 would remain unpinned. The authors belief is that the issues that arise from either implementations are artifacts of the implementation and distribution of preloaded pins, rather than an issue intrinsic to this specification. Tha= t is, the "correct" answer is that the preloaded pin list should be updated for Site 1 - however that information is distributed between the site operator and the creator of the preloaded pin list. Are there concerns with this interpretation, or can we close out Issue 55= ? From ryan-ietfhasmat@sleevi.com Mon Mar 4 16:58: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 28F0021F890E for ; Mon, 4 Mar 2013 16:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 uOu8HhPgF6iV for ; Mon, 4 Mar 2013 16:58:14 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9F30621F890D for ; Mon, 4 Mar 2013 16:58:14 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 6AC672F4060 for ; Mon, 4 Mar 2013 16:58:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :date:subject:from:to:reply-to:mime-version:content-type: content-transfer-encoding; s=sleevi.com; bh=nB9QkoXANcQ21BBQAfro vtj2OfI=; b=omlGVFLzw/wFxjxK1L+JHgv4niRlfqcJcflgccy5aYG2eLjBX7fu 22G28NMC7xMNUn077JSHbn58dTD5uoL+PCAdKVljqdmam+Wm+ylu2m8k3j+R/95M VwW2mWITJIXOvV+yZwm8oSRSjMuRISE2dtoI1fADHGoALdmD5mvQh/c= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPA id 4BD3D2F4057 for ; Mon, 4 Mar 2013 16:58:14 -0800 (PST) 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, 4 Mar 2013 16:58:14 -0800 Message-ID: <7c236f42fda755021433a4fd0ee04721.squirrel@webmail.dreamhost.com> Date: Mon, 4 Mar 2013 16:58:14 -0800 From: "Ryan Sleevi" To: websec@ietf.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [websec] Issue 56 - specify includeSubDomains for key pinning 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, 05 Mar 2013 00:58:15 -0000 With Key Pinning being split out from HTTP Strict Transport Security, one aspect that was lost was the includeSubDomains directive. This was raised as Issue 56 - http://trac.tools.ietf.org/wg/websec/trac/ticket/56 - against draft-03 draft-04 introduces the same directive, and with the same semantics, in Section 2.1.2 - http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1.2 Is the added language acceptable? Are there any concerns with the validation/processing model that would prevent us from closing out this issue? From ryan-ietfhasmat@sleevi.com Mon Mar 4 17:09: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 04F9A11E80D5 for ; Mon, 4 Mar 2013 17:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 DbCaBsj4b4Go for ; Mon, 4 Mar 2013 17:09:37 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 400D111E80AE for ; Mon, 4 Mar 2013 17:09:36 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 0EC271006D for ; Mon, 4 Mar 2013 17:09:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :date:subject:from:to:reply-to:mime-version:content-type: content-transfer-encoding; s=sleevi.com; bh=UXXRMFBfb0YG5U22McCr lgJgoJ4=; b=YulwtiiUkCrrIpQtJBOrjz/KCs2OQ1ev/r34HjwjzfOis5No96yM wweZvDqN9Dc6IItQ8ldzDWFqz7bRX3A23cIgLoA8BK11aknAD0rl8WcOMQGo2LXw bGLYAB5hg5CEE6nFIYiY/+RsTC9yk8FulNOKI2VYbMugRhgce2V6E4E= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPA id 01DCC10062 for ; Mon, 4 Mar 2013 17:09:35 -0800 (PST) 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, 4 Mar 2013 17:09:36 -0800 Message-ID: <0e3af2fc9efa802944efa946a800b62b.squirrel@webmail.dreamhost.com> Date: Mon, 4 Mar 2013 17:09:36 -0800 From: "Ryan Sleevi" To: websec@ietf.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [websec] Issue 54 - Adding a report-only mode 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, 05 Mar 2013 01:09:38 -0000 As discussed during Atlanta, and as raised in http://trac.tools.ietf.org/wg/websec/trac/ticket/54 , there's a strong desire for a Content Security Policy-like report and report-only mode. The use of a report mode is not as an attack mitigation, but as a way of sites to be informed of misconfigurations. The use of a report-only mode is as a way to allow sites to experiment with and deploy a Pinning Policy effectively. Given that pinning is effectively ultimately dependent on client trust and PKI policies, it's important for site operators to be able to ensure their proposed pinning policy will work effectively. To that end, draft-04 has introduced the report-uri directive, Section 2.= 1.3, http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1.3 , which allows a site to specify a URL to direct reports, as described in Section 3 - http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-3 In addition, and in the spirit of CSP, we'd like to propose the addition of a Public-Key-Pins-Report-Only header, as described in Section 2.1 http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1 -= =20 as a compliment to the Public-Key-Pins header. This header would follow the same syntax and semantics of the Public-Key-Pins header, with the exception of not actually enforcing the pins (as described Section 2.6). I'd like to solicit feedback and make sure that both the discussions from Atlanta and from the list have been accurately captured. Are there concerns with a Report-Only mode that have not been accurately captured? From dkg@fifthhorseman.net Tue Mar 5 02:26: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 4164321F8928 for ; Tue, 5 Mar 2013 02:26:50 -0800 (PST) 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 PVYs3m4v1w5d for ; Tue, 5 Mar 2013 02:26:49 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 93EC421F890F for ; Tue, 5 Mar 2013 02:26:49 -0800 (PST) Received: from [192.168.13.131] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 67D9BF979; Tue, 5 Mar 2013 05:26:47 -0500 (EST) Message-ID: <5135C860.2080001@fifthhorseman.net> Date: Tue, 05 Mar 2013 05:26:40 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130112 Icedove/17.0.2 MIME-Version: 1.0 To: ryan-ietfhasmat@sleevi.com References: <77ade868e5042a347751a9d025b84b19.squirrel@webmail.dreamhost.com> In-Reply-To: <77ade868e5042a347751a9d025b84b19.squirrel@webmail.dreamhost.com> X-Enigmail-Version: 1.6a1pre Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2CNEFMNBILTNRKMONFNPM" Cc: websec@ietf.org Subject: Re: [websec] Issue 53 - Key pinning should clarify status of pin validation with private trust anchors 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, 05 Mar 2013 10:26:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2CNEFMNBILTNRKMONFNPM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/04/2013 07:57 PM, Ryan Sleevi wrote: > As discussed during Atlanta, the way that pinning is currently implemen= ted > within Google Chrome, pinning is only enforced as it relates to so-call= ed > "public trust anchors" (eg: those shipped by default as part of a brows= er > or OS installation, not those installed by a user). Sorry -- i wasn't in Atlanta, so i don't know the context or background for this. Can you explain more? Consider the case where pre-loaded trust anchor ("trusted root certificate authority") X certified my web server's EE certificate with pubkey Y, and i published a pin on Y and my backup pubkey Z (but no pin on X). Are you saying that if i switch my server to use Z, and it is certified by some non-(pre)loaded trust anchor (or it is self-signed), then Google Chrome will not respect the pinning and the connection will fail? --dkg ------enig2CNEFMNBILTNRKMONFNPM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJRNchgXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpJo8P/1P0sLU4kqO5MrVo811DhYu0 ihZtf4WTzEnqCnNJ0V0Sa4VuQ3wrczsG6aRVegzNnM6s0VSi9ZFrtLngZq651YpB aScGgbXeNWhcVmYtM52BHcgad/MLeQC9HuX4sRGtratMgoHB/ZeJN2eAPR2YIKpc GNaRYX/avyYFOU2RCKT0mgCwcnAnLHD8OHufwsne2V9mSv2X6aU78WcMpoxeKhqM 4PMEhql0Opd8tdc/APwyD7Vz/QetvxhI7ZLcNPyPVUbByQTX//XjflEhNtOr/R85 dbNxiPfqHkLjFdNxoVWYIWMhSVyxuC3XUx8Abd2cmumFioOY7eXvmCPFdkjAtLT8 bb254c3rqhVfbBHZF4xms3FyCwrDK36u58+zLvxx5+GyJeRU7uaLzoMAXFPgSpeH fwB3G9vpfMkhc4AbRoi0o8ciB8mtTK5GD9AWe0Bqg5sEQWtjl3xwS06og9u02yaw hBwg2ic5iBU38BxWcFKVj6fFIj1wx6VkI6YDlThNLpkFgVP9XnxbV7Nf35UGhbpq zoaNwm+b5CzUHtlLRIWWSNsZBBlBS3E6YofvJNGEppNLjRiTIBv8ffWdV9A55vBc Tc051EeaaJZ7bMYvwwMbWsEIntRVGNCLZCstfHLiHdf3f28g7L6DN8L/VXNNt86H Vece/7kbZBBbhM/xR5Rk =78aK -----END PGP SIGNATURE----- ------enig2CNEFMNBILTNRKMONFNPM-- From ynir@checkpoint.com Tue Mar 5 03:18: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 BD1EC21F86BC for ; Tue, 5 Mar 2013 03:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.301, 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 Ju3VKyUfj3TT for ; Tue, 5 Mar 2013 03:18:01 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id AA69221F86A1 for ; Tue, 5 Mar 2013 03:18:00 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r25BHuSD004131; Tue, 5 Mar 2013 13:17:56 +0200 X-CheckPoint: {5135D40D-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.95]) with mapi id 14.02.0342.003; Tue, 5 Mar 2013 13:17:56 +0200 From: Yoav Nir To: Daniel Kahn Gillmor Thread-Topic: [websec] Issue 53 - Key pinning should clarify status of pin validation with private trust anchors Thread-Index: AQHOGTxpue254jfRf0afSx12uHk+Q5iWw9kAgAAOW4A= Date: Tue, 5 Mar 2013 11:17:55 +0000 Message-ID: <76607A26-B747-4728-8133-AF57C5B709A9@checkpoint.com> References: <77ade868e5042a347751a9d025b84b19.squirrel@webmail.dreamhost.com> <5135C860.2080001@fifthhorseman.net> In-Reply-To: <5135C860.2080001@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.198] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <4B1A4D0E49CC4D4E9F46416F47ACEDAD@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [websec] Issue 53 - Key pinning should clarify status of pin validation with private trust anchors 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, 05 Mar 2013 11:18:05 -0000 On Mar 5, 2013, at 12:26 PM, Daniel Kahn Gillmor wrote: > On 03/04/2013 07:57 PM, Ryan Sleevi wrote: >> As discussed during Atlanta, the way that pinning is currently implement= ed >> within Google Chrome, pinning is only enforced as it relates to so-calle= d >> "public trust anchors" (eg: those shipped by default as part of a browse= r >> or OS installation, not those installed by a user). >=20 > Sorry -- i wasn't in Atlanta, so i don't know the context or background > for this. Can you explain more? >=20 > Consider the case where pre-loaded trust anchor ("trusted root > certificate authority") X certified my web server's EE certificate with > pubkey Y, and i published a pin on Y and my backup pubkey Z (but no pin > on X). >=20 > Are you saying that if i switch my server to use Z, and it is certified > by some non-(pre)loaded trust anchor (or it is self-signed), then Google > Chrome will not respect the pinning and the connection will fail? Hi Daniel Not respecting the pinning means that the connection will not fail. Suppose the trust anchor store that comes with the OS on which Chrome is in= stalled comes with two CAs: Verisign and StartCom.=20 My computer also has another CA called BigCorpCA. Suppose some website, such as tools.ietf.org has published a pin for Verisi= gn. Chrome will accept a certificate from Verisign, because it fits the pin Chrome will accept a certificate from BigCorpCA, because it was added by th= e user (or by someone who has enough power over the user to install CAs on = their computer) Chrome will not accept a certificate from StartCom, because it goes against= the PIN. I can guess that the reason they do this is so that Chrome doesn't block on= certificates from TLS proxies, that are becoming increasingly common. Yoav (with no hats)= From tom@ritter.vg Tue Mar 5 18:55: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 ABBE921F8609 for ; Tue, 5 Mar 2013 18:55:21 -0800 (PST) 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 K6RAcyrjsC3T for ; Tue, 5 Mar 2013 18:55:21 -0800 (PST) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id F40A221F8501 for ; Tue, 5 Mar 2013 18:55:20 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id m18so4529783vcm.22 for ; Tue, 05 Mar 2013 18:55:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=/UceY41udfLo9Sm2pVDdb7lMJSRR93duCcNhg2WPlsY=; b=L9Agu+GkqBDG0y663ol2QmZ/l1QJgdgePC2kp89w11mNRv9JJq+Te2LrIWQvUPwUqK DXkwYjUARZV8/KnYAxrCvA26Z+ryYuJMBYGwhvBKtYG4kBjpmqhvE1lEhWWVWmvP3yL4 7mFGS+qC/7XxqkVBQfXpb6LbCAzScLEO71JxI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=/UceY41udfLo9Sm2pVDdb7lMJSRR93duCcNhg2WPlsY=; b=oYEWLRBuA0WawpicPz7Gxcnpiz7yz8qzFQzjiWhmfNNXzLbldrYU+lC5fUhy7x5wO9 yJ9JOCRKhk1EGTotSx4LEgxgYRal7tmFJli7Qszohqd1d7S7+5k0hI/Guixv+5RSQCFK OCsFQ9YWM3wercQxm2C3nO/cuKLc+Yz2Bz1m6gOpXEbP9T+kv+ie/U+E+5p7PzGVFOzq B76Fxc+TFiXV+Nf2gAr6ZL+Xw95yGakmHRbRvoQJ3OOqoGoun3fiIVc43E1FKuazgEPb X2PieKwHFuGCnL7qRUlKxknxWq+jnCV0Lolrlx92Hhge0svD+BltGaY4RCrwhShUIxEL nBMA== X-Received: by 10.52.91.212 with SMTP id cg20mr9494911vdb.63.1362538520196; Tue, 05 Mar 2013 18:55:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.182.169 with HTTP; Tue, 5 Mar 2013 18:54:58 -0800 (PST) In-Reply-To: <77ade868e5042a347751a9d025b84b19.squirrel@webmail.dreamhost.com> References: <77ade868e5042a347751a9d025b84b19.squirrel@webmail.dreamhost.com> From: Tom Ritter Date: Tue, 5 Mar 2013 21:54:58 -0500 Message-ID: To: ryan-ietfhasmat@sleevi.com Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmfopKDFMrPeNnnkoX1e074LnSBb0xvMCNFZn7Co0MLQpBR+OZl9QL3maqG1KU3erlPKNmR Cc: websec@ietf.org Subject: Re: [websec] Issue 53 - Key pinning should clarify status of pin validation with private trust anchors 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, 06 Mar 2013 02:55:21 -0000 On 4 March 2013 19:57, Ryan Sleevi wrote: > While there is an open question as to whether or not such user-agent > behaviour is appropriate to specify here, does the group feel the proposed > text sufficiently addresses the issue as originally raised? I think it does, although I'm very curious about two points: - will implementations respect 'strict'? - who if any of the sites that have led the way on HSTS/pinning (Google, Twitter) will enable strict I guess we'll have to wait and see. -tom From tom@ritter.vg Tue Mar 5 18:55: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 CC93411E80D5 for ; Tue, 5 Mar 2013 18:55:27 -0800 (PST) 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 75JCQ1hyZyac for ; Tue, 5 Mar 2013 18:55:27 -0800 (PST) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5240611E80A5 for ; Tue, 5 Mar 2013 18:55:27 -0800 (PST) Received: by mail-ve0-f181.google.com with SMTP id d10so6386411vea.12 for ; Tue, 05 Mar 2013 18:55:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=y1Efef0AB6q5tGWjcldPPbUWJcQFScLKshZSlgTbjpo=; b=fdwPJwyXgxXtoFqVs7I4Hk6pYAnIrWxxp9/UUVdQ4bYqBB3f/ZMic61B/8ZSQoVVx4 PxKolvfrsax30dwqcld6DIBdQ86xP2LMuRttVQ5GqBWeJY6aE8vM08t4poxtZSTtfiFI 4MaW601y+ylUhY9Sw27fSGevPhc+iV7cjUlBY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=y1Efef0AB6q5tGWjcldPPbUWJcQFScLKshZSlgTbjpo=; b=lLbpPc1M6xs5E/dWxCnZ94iZLwYpfPOFNwQQhxcutt1fxk+AdYp/BFwpPzPAg3nVja zO+UzTlUx/isG90faFLTjwNCbpGrgiQDa1sEx8JEZ/zdeZZJX3A6Ij10hoEqHXu0ZFuX jGo6oObixwC8GhrklEkCbf34r76xNOyEu/KW0Rz8bCmc1+YGO1wyOq4qAuDPbPVm0iIF CkedqUtvL3YVoyJ4f33ZPWZyY9012c0W4YvzJmXnHNmf6JHB99PazybeBfMfO5QjKo3Z ISfyHJDlI1fFpcn0lWcNvjhd4G/HPqCEMGaLwW00YC2QXHbxAkBrT8VU6/CxTJT+W1nT SdLA== X-Received: by 10.221.11.135 with SMTP id pe7mr10627715vcb.41.1362538526641; Tue, 05 Mar 2013 18:55:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.182.169 with HTTP; Tue, 5 Mar 2013 18:55:06 -0800 (PST) In-Reply-To: <0e3af2fc9efa802944efa946a800b62b.squirrel@webmail.dreamhost.com> References: <0e3af2fc9efa802944efa946a800b62b.squirrel@webmail.dreamhost.com> From: Tom Ritter Date: Tue, 5 Mar 2013 21:55:06 -0500 Message-ID: To: ryan-ietfhasmat@sleevi.com Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnaoAb0FIv6IMp3NK85laneK8fs1fcyDr6jWtJsWx63HPExHxEZr4zNlrRKFoHK17YZQwpJ Cc: websec@ietf.org Subject: Re: [websec] Issue 54 - Adding a report-only mode 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, 06 Mar 2013 02:55:27 -0000 On 4 March 2013 20:09, Ryan Sleevi wrote: > I'd like to solicit feedback and make sure that both the discussions from > Atlanta and from the list have been accurately captured. Are there > concerns with a Report-Only mode that have not been accurately captured? Obviously I wasn't in Atlanta, but I feel if you're sending the known pins in the report (and you should) you should send the whole policy as you know it, including directives, and some mechanism for max-age that says 'when I think this will expire'. Maybe even 'when I got this directive' (if available) and 'where i got this directive from' (preloaded vs header). port should be an integer or a string, but one or the other. Why have it be ambiguous? -tom From tom@ritter.vg Tue Mar 5 18:55: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 4FD1321F8615 for ; Tue, 5 Mar 2013 18:55:49 -0800 (PST) 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=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_17=0.6, 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 8tn6cLuq9pfj for ; Tue, 5 Mar 2013 18:55:48 -0800 (PST) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2DC21F8501 for ; Tue, 5 Mar 2013 18:55:47 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id p16so4667657vcq.29 for ; Tue, 05 Mar 2013 18:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=jp4Bx/p3cMJV965GVjBFTWnXWfRM61CG8oTgcq0HktM=; b=MGOiuZwgGQOWjGcmus/hmmnUaAKeMDxmR8gZvqpqDZk4jc4ibaR+O2zPdbJLKi7G7/ 0D+ToEhXdwvzx9GnkJxsnEF//nnwigVW/kOUv9Q1D0OqKNmG54g9yyENn8GuV2/yEm/U 5vRVuXOMvJsqSvR217Vp+CzObgWquVBqj7AZc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=jp4Bx/p3cMJV965GVjBFTWnXWfRM61CG8oTgcq0HktM=; b=D1YYoUF9/Dcb0p4+F3cgPItpitDs328ZT7zqxO8t2f53UwirdMz/rr0EXKCv85OYO1 hbtqfRlEev0acIsA1m+Baw3Pwxfc3gl0D6lIVsBXQt8G0s4YauAYRcvW34bhGDT79cqc BLHz+eQ8Mags4K184ArSN89lC9fcqRb9oOAwvK2ogdyFiKI1bii9EoAWKcwxviCLCsar dM3YLxg5YUaqDjwRlhIN5g54W56xpVoZ+yPGVHtnoceUuVIrmrMRRYNx7oXQ4vE5f5nO TTMIbYl569BDfZd/wUnuxyUQsORl224UgzZUpBb4RzHjsSo2M/3afe50mDO92DHz2Ct5 wE1w== X-Received: by 10.220.116.5 with SMTP id k5mr10629156vcq.55.1362538547498; Tue, 05 Mar 2013 18:55:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.182.169 with HTTP; Tue, 5 Mar 2013 18:55:27 -0800 (PST) In-Reply-To: <7c236f42fda755021433a4fd0ee04721.squirrel@webmail.dreamhost.com> References: <7c236f42fda755021433a4fd0ee04721.squirrel@webmail.dreamhost.com> From: Tom Ritter Date: Tue, 5 Mar 2013 21:55:27 -0500 Message-ID: To: ryan-ietfhasmat@sleevi.com Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmN/G71a9sJOVvT7wMXogiPmAddbaEXb3Xsztmh5E8/cghyaHn6S/xZS7M11Ti79Tz6XZj1 Cc: websec@ietf.org Subject: Re: [websec] Issue 56 - specify includeSubDomains for key pinning 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, 06 Mar 2013 02:55:49 -0000 On 4 March 2013 19:58, Ryan Sleevi wrote: > Is the added language acceptable? Are there any concerns with the > validation/processing model that would prevent us from closing out this > issue? It took me a while to get it (so maybe a clarification appendix would be good?), but I think I do and I think it works. Although, I suppose there's no real support for a mechanism where exmaple.com has includeSubdomains that applies to a, b, c.example but d.example says "max-age=0". D will wind up being pinned regardless. I think that's okay, just noting it. As an aside, Section 2.3.1 says "Note the host as a Known HSTS Host if it is not already so noted" I think that should be "Known Pinned Host"? I thought we were separating Require-SSL from Require-These-Keys. -tom From tom@ritter.vg Tue Mar 5 18:56: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 8262621F85B4 for ; Tue, 5 Mar 2013 18:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=0.060, 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 2LskvOE6HPVM for ; Tue, 5 Mar 2013 18:56:03 -0800 (PST) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id E6BD321F8501 for ; Tue, 5 Mar 2013 18:56:02 -0800 (PST) Received: by mail-ve0-f181.google.com with SMTP id d10so6245444vea.26 for ; Tue, 05 Mar 2013 18:56:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=epb5Ls3B2Az6Ua2N7bO4KrgWsrZKZOPwcvw+hOL1ohU=; b=gPQLyFU2l9IkHNDdiLKMRQXF0sqVZ5b8OgLhGbf5fGTusznr+sBjhEY2zoj0kTurN/ m7gjbk8ovCzsuxzsWoimffBE5sdtOOLjsN8dLKUaijIVXpMLw/PcgtTypmJdmPKX70zc FHoofJ+od0IoguJCZPUztGP6DIRB+2jzT5zaQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=epb5Ls3B2Az6Ua2N7bO4KrgWsrZKZOPwcvw+hOL1ohU=; b=T2HM1KbP6uG08hCKtkLBMl15pWZxB8GvGuQ/yEFvdKte7VmQDii4JWN2TzywmzBm/e kUZ9D9Wl+UGmlwXl90ePkzfn+kQ+y1vJdXSxZYpz5QDRefDAwGAKOs0tAjagYmrlP/ij 9f9DIsljbqCOE3Kk0VT5LpXYxsN9fVO0l4VFMtu7OpJ7IoI+4uu40ofCwsIjbCkQVekC kFJRTgvqwn92o83+Y34b707xQh3SNbXPv3i5yyMkgiakta+hXKDRXU0EVB3Q2pdKUsSC TR07x6S3AJ6d6BWTt5l2dd2HPT8FkkgK9MgM6AswuEdSmwhjz4egjeQWxLai8nCf7CvN cbCQ== X-Received: by 10.58.12.69 with SMTP id w5mr10962608veb.16.1362538562373; Tue, 05 Mar 2013 18:56:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.182.169 with HTTP; Tue, 5 Mar 2013 18:55:42 -0800 (PST) In-Reply-To: References: From: Tom Ritter Date: Tue, 5 Mar 2013 21:55:42 -0500 Message-ID: To: ryan-ietfhasmat@sleevi.com Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlBaWrNcvyIvg3RabyeqwoMbtK0lO8ATVGTDgRtEa6zdBBTRVSOMzaplbSPxG5plfP/+6lB Cc: websec@ietf.org Subject: Re: [websec] Issue 55 - Key pinning should clarify that the newest pinning information takes precedence 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, 06 Mar 2013 02:56:03 -0000 On 4 March 2013 19:57, Ryan Sleevi wrote: > The authors belief is that the issues that arise from either > implementations are artifacts of the implementation and distribution of > preloaded pins, rather than an issue intrinsic to this specification. That > is, the "correct" answer is that the preloaded pin list should be updated > for Site 1 - however that information is distributed between the site > operator and the creator of the preloaded pin list. > > Are there concerns with this interpretation, or can we close out Issue 55? I guess I'm just confused. I agree it's rife for implementation differences, but I either A) Incorrectly parse this as punting on guidance that would (try to) achieve parity across implementations and prevent yet another thing that webmasters need to understand when requesting preloading in multiple browsers b) Correctly parse it as such, but don't understand why you would punt on expressing a standard behavior instead. -tom From tom@ritter.vg Tue Mar 5 18:56: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 B587C21F8611 for ; Tue, 5 Mar 2013 18:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, 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 IcdCG5dNWHhY for ; Tue, 5 Mar 2013 18:56:59 -0800 (PST) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id 37E3F21F860A for ; Tue, 5 Mar 2013 18:56:59 -0800 (PST) Received: by mail-ve0-f180.google.com with SMTP id jx10so6389080veb.11 for ; Tue, 05 Mar 2013 18:56:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=L6/L7miy3MZRmVPFZSg62pm4SA/yBPRc6na40t+S8DY=; b=gzFKTzY4kbkks1RjTLxbAMjQ9Px6GnuhkQFmSeekJb94bV2QE+kigNln1yIIgutE2N EXlTG6+HxT71Sxk6n/V2LXemrkYXFym4jm8YMzB+x+y8Y3R+0x+L0PDk1swT4psi3m9/ qULtgDdFA3x+5mzwCHo9ZGWg6UIPj/FmUmgUk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=L6/L7miy3MZRmVPFZSg62pm4SA/yBPRc6na40t+S8DY=; b=KX8EjM/COkR7VvP9KwzTtt4GiI46OUTHJyOEYw/hxcDHIBl13ax9Z4Q+/+UUn1i0pT 4DG5j1nc7XwdftNDO6cQsp50Mjw7lw0dbRAWMqxyZ6VpXWiq8TPK14TSjUZbb/Nc9z5u SFP4yLOVk55QuBJR5n0azwy2UG1v+kM7Veo3xvJV13urABXUlxuwZzWTrfs4W+SzZHeQ l5Xrua7vzTr9LjpctZJ1wzwNez0FO95JnsqGAGCCHSm213FbUnPGdnUFLXLGB3LvZ+kv bjSWkzTtsw6DLNGzTbtkhGfngc7wqTfCjcdUAh0aFQAeZTe6dEFMJcp+ig4aFIdrbbaY +1Bw== X-Received: by 10.58.245.200 with SMTP id xq8mr11012744vec.21.1362538618639; Tue, 05 Mar 2013 18:56:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.182.169 with HTTP; Tue, 5 Mar 2013 18:56:38 -0800 (PST) In-Reply-To: References: From: Tom Ritter Date: Tue, 5 Mar 2013 21:56:38 -0500 Message-ID: To: ryan-ietfhasmat@sleevi.com Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk9pozPee/+jHOxpS04zGhtS+nV9G0VgmVYGgstgEJcfvuBDkREgEl732lPhOEfgtCnZ42A Cc: websec@ietf.org Subject: Re: [websec] Issue 52 - Key pinning draft should clarify max-age as required 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, 06 Mar 2013 02:56:59 -0000 No objection to closing it out. On 4 March 2013 19:56, Ryan Sleevi wrote: > This was one of the outstanding issues from draft-03, raised in > http://trac.tools.ietf.org/wg/websec/trac/ticket/52 > > The Chrises and I believe this has been addressed sufficiently in > draft-04, through the clarifications in > http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1.1 and > http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.3.1 > > Are there any objections to closing this out? > > > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From ryan-ietfhasmat@sleevi.com Wed Mar 6 11:34: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 520CB21F8CBD for ; Wed, 6 Mar 2013 11:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 DfrEJvUiOAgN for ; Wed, 6 Mar 2013 11:34:18 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 37A4111E80C5 for ; Wed, 6 Mar 2013 11:34:18 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id E0DCE94075; Wed, 6 Mar 2013 11:34:17 -0800 (PST) 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=d4bWOvKAWeMQ1SuSW7FKSimC1oI=; b=naDtf3HS50XYPR6+0 sl49vGCSCrSRhl4OMZEtlOwp5FCEBmZiXJe1iSM5Vm5fRxh89q3sbmGjz9hZQKKj jAigvSMXHY0czUFW7g+/s7purtHm1RzkidN6iYqZ8HwG/EDAtItHZNWlWlpAm7PV cRG9wGJWVExHfyC9Q6/KGLApWQ= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPA id 9CC849406E; Wed, 6 Mar 2013 11:34:17 -0800 (PST) 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, 6 Mar 2013 11:34:17 -0800 Message-ID: <213eca1a2bae6a02699751dbe9691167.squirrel@webmail.dreamhost.com> In-Reply-To: References: Date: Wed, 6 Mar 2013 11:34:17 -0800 From: "Ryan Sleevi" To: "Tom Ritter" 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] Issue 55 - Key pinning should clarify that the newest pinning information takes precedence 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, 06 Mar 2013 19:34:22 -0000 On Tue, March 5, 2013 6:55 pm, Tom Ritter wrote: > On 4 March 2013 19:57, Ryan Sleevi wrote: > > The authors belief is that the issues that arise from either > > implementations are artifacts of the implementation and distribution = of > > preloaded pins, rather than an issue intrinsic to this specification. > > That > > is, the "correct" answer is that the preloaded pin list should be > > updated > > for Site 1 - however that information is distributed between the site > > operator and the creator of the preloaded pin list. > > > > Are there concerns with this interpretation, or can we close out Issu= e > > 55? > > I guess I'm just confused. I agree it's rife for implementation > differences, but I either > A) Incorrectly parse this as punting on guidance that would (try to) > achieve parity across implementations and prevent yet another thing > that webmasters need to understand when requesting preloading in > multiple browsers > b) Correctly parse it as such, but don't understand why you would punt > on expressing a standard behavior instead. > > -tom > I think the real answer should be that preloading shouldn't be part of th= e spec, as it really is an implementation-specific behaviour. Certainly, it's based on our experiences in Chrome/Chromium, and it does provide an additional measure of security for the initial connection, but it doesn't really tie into the semantics of the header at all. Different applications - including such like Firefox - have already expressed interest in pursuing different schemes for preloading and the maintenance of such lists. Certainly, we've looked at alternatives ourselves. Our thinking is that we should avoid baking such behaviours into a spec, and instead focus solely on the header and observation aspects. Unlike the header - which is presumably provided to all user agents and uniform implementation expected - preloading is (at least, today) about a relationship between the site operator and individual user agents, so there's already a communication channel. If other implementations pursue different schemes - eg: such as crawling and noting pins - then they may have vastly different needs/requirements, but the overall semantics of th= e header itself remains the same. From ynir@checkpoint.com Wed Mar 6 12:45: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 9FEEC21F8C4E for ; Wed, 6 Mar 2013 12:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 C3yKR8se2d7i for ; Wed, 6 Mar 2013 12:45:11 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 477FE21F8C1A for ; Wed, 6 Mar 2013 12:45:10 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r26Kj9IP017211; Wed, 6 Mar 2013 22:45:09 +0200 X-CheckPoint: {5137AA6A-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.95]) with mapi id 14.02.0342.003; Wed, 6 Mar 2013 22:45:09 +0200 From: Yoav Nir To: Tom Ritter Thread-Topic: [websec] Issue 52 - Key pinning draft should clarify max-age as required Thread-Index: AQHOGTxgXL1HU6c700CGCKOcR8J+spiX2HEAgAEqjIA= Date: Wed, 6 Mar 2013 20:45:09 +0000 Message-ID: <827E3E53-CFBC-4CF6-9E26-B02673F90B32@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.73] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <576D49CF42B6734BB0C059307D4D95DD@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [websec] Issue 52 - Key pinning draft should clarify max-age as required 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, 06 Mar 2013 20:45:15 -0000 I agree as well. If we don't hear any objections on the list or at the meeting, we'll close = this issue following the meeting. Yoav On Mar 6, 2013, at 4:56 AM, Tom Ritter wrote: > No objection to closing it out. >=20 > On 4 March 2013 19:56, Ryan Sleevi wrote: >> This was one of the outstanding issues from draft-03, raised in >> http://trac.tools.ietf.org/wg/websec/trac/ticket/52 >>=20 >> The Chrises and I believe this has been addressed sufficiently in >> draft-04, through the clarifications in >> http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1.= 1 and >> http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.3.= 1 >>=20 >> Are there any objections to closing this out? >>=20 From derhoermi@gmx.net Wed Mar 6 17:05: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 2AD6321F8763 for ; Wed, 6 Mar 2013 17:05:34 -0800 (PST) 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] 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 HBvMo81BhdI0 for ; Wed, 6 Mar 2013 17:05:33 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0C91021F8754 for ; Wed, 6 Mar 2013 17:05:33 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.16]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LoKSF-1Uk13q3b4b-00gEKz for ; Thu, 07 Mar 2013 02:05:31 +0100 Received: (qmail invoked by alias); 07 Mar 2013 01:05:31 -0000 Received: from p5B233298.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [91.35.50.152] by mail.gmx.net (mp016) with SMTP; 07 Mar 2013 02:05:31 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1++Z089tum+17Y/0WT67BjaNPlM9y9cPwljUJ+Tg6 ypdcyGrjEAp8q9 From: Bjoern Hoehrmann To: Bjoern Hoehrmann Date: Thu, 07 Mar 2013 02:05:33 +0100 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Wed, 06 Mar 2013 17:14:35 -0800 Cc: ietf-message-headers@ietf.org Subject: Re: [websec] [Ietf-message-headers] HTTP 'Origin' permanent and provisional 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, 07 Mar 2013 01:05:34 -0000 * Bjoern Hoehrmann wrote: > http://www.iana.org/assignments/message-headers/prov-headers.html and >http://www.iana.org/assignments/message-headers/perm-headers.html list >the "Origin" header for HTTP, one per RFC 6454 and one from an earlier >W3C registration. Is that as it should be? This has been fixed on http://www.iana.org/assignments/message-headers and the two addresses above have been changed to indicate they are now obsolete (and should, instead, redirect to the new address soon). -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From tom@ritter.vg Wed Mar 6 18:50: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 68BF011E80F0 for ; Wed, 6 Mar 2013 18:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.758 X-Spam-Level: X-Spam-Status: No, score=-2.758 tagged_above=-999 required=5 tests=[AWL=0.219, 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 27eKbbK4ZGKQ for ; Wed, 6 Mar 2013 18:50:03 -0800 (PST) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7C01D11E80E9 for ; Wed, 6 Mar 2013 18:50:03 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id k1so5201917vck.38 for ; Wed, 06 Mar 2013 18:50:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=rkl1g/uAYPurfnExCgfNgYayecFKxhSoMXEBQ3YayAM=; b=mIBmUmv0dhob2r+sMikCHlDV0LTy+Dtj8lJsCu+Ei1OOAOY7zwPqmk5fdKastWnX+e VH29kkYU743iFO8c6ubYG/ddnTJEktOYumKhE9WnA9onR1DAiFABo2eON8cq5Qnv9c/E oU/I/O+MVmCvLkkYZNbzph94/TAYevBrM+oA8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=rkl1g/uAYPurfnExCgfNgYayecFKxhSoMXEBQ3YayAM=; b=ZmoZPfgGiEkr6aV5J4txbvXXc+wCUFSo1fhy4laYzuvbOaS7BHByNh35nFnJtiy5kE pT3zANmSe+ITIiW9stXCxQUdNGCpzqDFyDKIJUJFE7gwCEftbBzn9ecIVFVXBOufFYKW zAihIBWgbYclmYWHWcDSz7WcZql+6nqk1/jjIH1hjJAL05/jZ9MpOyILBbMwzJNOJl+u 7JIPif2/zUtxWpEad66S2j5VSUljFtm5vOPVqOH9bhNEImFW8/VsuknKYATTjfTDMsVS WmOdDN0xkoxrl8UqwpZt+wQUfiD+xubzYDSbkV0mm3NIroPj9GxtoJF4/96F/Znxe/Y9 aavQ== X-Received: by 10.58.46.134 with SMTP id v6mr12676910vem.45.1362624602766; Wed, 06 Mar 2013 18:50:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.182.169 with HTTP; Wed, 6 Mar 2013 18:49:42 -0800 (PST) In-Reply-To: <213eca1a2bae6a02699751dbe9691167.squirrel@webmail.dreamhost.com> References: <213eca1a2bae6a02699751dbe9691167.squirrel@webmail.dreamhost.com> From: Tom Ritter Date: Wed, 6 Mar 2013 21:49:42 -0500 Message-ID: To: ryan-ietfhasmat@sleevi.com Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlmJm2ApiED3Fh5Gb05AWIY/KC40r8GyX94EyA5pEODuhbnX1qHZ3KOUyIgHq+Q5lY1znD1 Cc: websec@ietf.org Subject: Re: [websec] Issue 55 - Key pinning should clarify that the newest pinning information takes precedence 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, 07 Mar 2013 02:50:04 -0000 On 6 March 2013 14:34, Ryan Sleevi wrote: > I think the real answer should be that preloading shouldn't be part of the > spec, as it really is an implementation-specific behaviour. Certainly, > it's based on our experiences in Chrome/Chromium, and it does provide an > additional measure of security for the initial connection, but it doesn't > really tie into the semantics of the header at all. > > Different applications - including such like Firefox - have already > expressed interest in pursuing different schemes for preloading and the > maintenance of such lists. Certainly, we've looked at alternatives > ourselves. Our thinking is that we should avoid baking such behaviours > into a spec, and instead focus solely on the header and observation > aspects. > > Unlike the header - which is presumably provided to all user agents and > uniform implementation expected - preloading is (at least, today) about a > relationship between the site operator and individual user agents, so > there's already a communication channel. If other implementations pursue > different schemes - eg: such as crawling and noting pins - then they may > have vastly different needs/requirements, but the overall semantics of the > header itself remains the same. Fair enough. I hope a browser will be willing to fiddle with their preloading mechanism if it's found to cause pain, and I hope any site owner would not put in preloaded pins with a browser that couldn't amend them easily. I'll only mention for consideration rewording the line to say "the newest information available for the host": UAs MUST use the newest information available for the host -- built-in or set via Valid Pinning Header -- when performing Pin Validation. This may guide things better without being overly restrictive. -tom From ynir@checkpoint.com Tue Mar 12 10:15: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 104FC11E80B8 for ; Tue, 12 Mar 2013 10:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.577 X-Spam-Level: X-Spam-Status: No, score=-10.577 tagged_above=-999 required=5 tests=[AWL=0.021, 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 UJDZHJB6i57G for ; Tue, 12 Mar 2013 10:15:46 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2B93711E80A5 for ; Tue, 12 Mar 2013 10:15:45 -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 r2CHFix9001400 for ; Tue, 12 Mar 2013 19:15:44 +0200 X-CheckPoint: {513F61FF-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.95]) with mapi id 14.02.0342.003; Tue, 12 Mar 2013 19:15:44 +0200 From: Yoav Nir To: IETF WebSec WG Thread-Topic: Slides uploaded Thread-Index: AQHOH0U7/ByHpPGxqUWNsPCtAhiOhg== Date: Tue, 12 Mar 2013 17:15:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.25] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_CCA09D5A03F2480F9788153C29ECF5FFcheckpointcom_" MIME-Version: 1.0 Subject: [websec] Slides uploaded 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, 12 Mar 2013 17:15:49 -0000 --_000_CCA09D5A03F2480F9788153C29ECF5FFcheckpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all. The agenda is updated and the meeting slides are not on the meeting materia= ls page. We will be discussing a proposal to replace the session cookie mechanism. F= or a comprehensive review of what is wrong with using cookies to maintain s= essions, you may want to read the document "Weaning the Web Off of Session = Cookies" [1]. We are not likely to have time to discuss all of these issues= , but we could be trying to solve them. Links: * Agenda: http://www.ietf.org/proceedings/86/agenda/agenda-86-websec * Slides: https://datatracker.ietf.org/meeting/86/materials.html#websec * Weaning the Web Off of Session Cookies: http://www.vsecurity.com/down= load/papers/WeaningTheWebOffOfSessionCookies.pdf Yoav [1] Not to be confused with "Weaning the IETF Off of inter-Session Cookies" --_000_CCA09D5A03F2480F9788153C29ECF5FFcheckpointcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5AC2CAB5FBA5F2478BD85053E96034EE@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable Hi all.

The agenda is updated and the meeting slides are not on the meeting ma= terials page.

We will be discussing a proposal to replace the session cookie mechani= sm. For a comprehensive review of what is wrong with using cookies to maint= ain sessions, you may want to read the document "Weaning the Web Off o= f Session Cookies" [1]. We are not likely to have time to discuss all of these issues, but we could be trying to sol= ve them.

Links:
Yoav

[1] Not to be confused with "Weaning the IETF Off of inter-Sessio= n Cookies"
--_000_CCA09D5A03F2480F9788153C29ECF5FFcheckpointcom_-- From ynir@checkpoint.com Wed Mar 13 19:29: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 CE17521F8ADC for ; Wed, 13 Mar 2013 19:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.586 X-Spam-Level: X-Spam-Status: No, score=-10.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 9NAsqHgrPOHu for ; Wed, 13 Mar 2013 19:29:22 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C21D821F8AD8 for ; Wed, 13 Mar 2013 19:29:21 -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 r2E2TGiD022050 for ; Thu, 14 Mar 2013 04:29:16 +0200 X-CheckPoint: {51413527-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.95]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 04:29:16 +0200 From: Yoav Nir To: IETF WebSec WG Thread-Topic: Preliminary Minutes Uploaded Thread-Index: AQHOIFu4mi9Jl5ldBU6h6pCiXPaWVg== Date: Thu, 14 Mar 2013 02:29:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.156] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [websec] Preliminary Minutes Uploaded 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, 14 Mar 2013 02:29:22 -0000 Hi all Following our meeting today, I have uploaded the preliminary meeting minute= s. Thanks again to Brad Hill for taking minutes during the meeting. Please send any corrections directly to me. Yoav Link: http://www.ietf.org/proceedings/86/minutes/minutes-86-websec= From hallam@gmail.com Wed Mar 13 20:49: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 0395521F87CC for ; Wed, 13 Mar 2013 20:49:56 -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 Ylu1uTb-0RqQ for ; Wed, 13 Mar 2013 20:49:55 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1540B21F8712 for ; Wed, 13 Mar 2013 20:49:54 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id t11so1731791wey.14 for ; Wed, 13 Mar 2013 20:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=Jrqww+eRY3pJbjFjBt1hvRux0ztgggAQqtuCCXBOemo=; b=IBsUvtjOYImWsqL66F+gP1OjmFcBTW81uolZYaBOzcBRxDchvF1eAdA5h1qewIWDqZ DDpUpebAjgbjAM3Fa0DK56Lq/6bVhhnqE0cLe5ojpEDwHp3sJ9CcJcW3zkVsaOobIuu6 G+BBBu/XOoVvW+6vhTa6yUmGj8DeNW5qgHBoF/GZBRRgQb7opeol4wfSjHuHpXUo6E+g YqaYusxwE6JGDmbzhbjnHjiXCgb2cNdFcllHr2MXeOgXvJ8plktZvV85C2rx+0OGBo8p MaSkomQ3illKlcoUySl8z1VSMAghR0F7ZmG9HLbYNKuUyq4rwWttpIP9paha2Y0LHkA7 2bYg== MIME-Version: 1.0 X-Received: by 10.180.74.131 with SMTP id t3mr31059602wiv.23.1363232994254; Wed, 13 Mar 2013 20:49:54 -0700 (PDT) Received: by 10.194.11.71 with HTTP; Wed, 13 Mar 2013 20:49:53 -0700 (PDT) Date: Wed, 13 Mar 2013 23:49:53 -0400 Message-ID: From: Phillip Hallam-Baker To: websec Content-Type: text/plain; charset=ISO-8859-1 Subject: [websec] Session Continuation = Session Bound State? 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, 14 Mar 2013 03:49:56 -0000 The main substantive query that seemed to be raised in the meeting was what we are going to call this session continuation thing. I am not that worried about confusion with HTTP-Auth. Folk who know, know. But one of the objectives here is to replace cookies. So choosing a name that positions the spec as a successor to authentication cookies is actually quite important. How about Session Bound State as the term of art? -- Website: http://hallambaker.com/ From trac+websec@trac.tools.ietf.org Thu Mar 14 09:43:07 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 5DFB411E8110 for ; Thu, 14 Mar 2013 09:43:07 -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 yvRyvPSg-JLg for ; Thu, 14 Mar 2013 09:43:06 -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 8193711E80E9 for ; Thu, 14 Mar 2013 09:43:06 -0700 (PDT) Received: from localhost ([127.0.0.1]:35560 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UGBF8-0007II-UF; Thu, 14 Mar 2013 17:43:02 +0100 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: palmer@google.com, ynir@checkpoint.com X-Trac-Project: websec Date: Thu, 14 Mar 2013 16:43:02 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/52#comment:2 Message-ID: <066.642de56d2e5fe4d34165723e9104fee1@trac.tools.ietf.org> References: <051.df0a7eb62cdb49309147ff5b8eb8e401@trac.tools.ietf.org> X-Trac-Ticket-ID: 52 In-Reply-To: <051.df0a7eb62cdb49309147ff5b8eb8e401@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, 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 Cc: websec@ietf.org Subject: Re: [websec] #52: Clarification of section 2.3.1 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: Thu, 14 Mar 2013 16:43:07 -0000 #52: Clarification of section 2.3.1 Changes (by ynir@checkpoint.com): * status: assigned => closed * resolution: => fixed Comment: Solved in -04 -- -------------------------+-------------------------------- Reporter: Tom Ritter | Owner: palmer@google.com Type: defect | Status: closed Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+-------------------------------- Ticket URL: websec From ynir@checkpoint.com Sun Mar 17 21:21: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 B1B7E21F8935 for ; Sun, 17 Mar 2013 21:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.375 X-Spam-Level: X-Spam-Status: No, score=-10.375 tagged_above=-999 required=5 tests=[AWL=0.223, 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 qVnfkkVtoBAb for ; Sun, 17 Mar 2013 21:21:20 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id EE57021F8925 for ; Sun, 17 Mar 2013 21:21:19 -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 r2I4LEed004475 for ; Mon, 18 Mar 2013 06:21:14 +0200 X-CheckPoint: {51469529-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Mon, 18 Mar 2013 06:21:14 +0200 From: Yoav Nir To: IETF WebSec WG Thread-Topic: Some issues with key-pinning Thread-Index: AQHOI5AGjmneSZSsgkm5XHxWc8tUNw== Date: Mon, 18 Mar 2013 04:21:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.240] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_F9AF39882F4345278AB3615D693C998Ccheckpointcom_" MIME-Version: 1.0 Subject: [websec] Some issues with key-pinning 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, 18 Mar 2013 04:21:21 -0000 --_000_F9AF39882F4345278AB3615D693C998Ccheckpointcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi I have reviewed this draft, and here are some comments. Section 2.1 last paragraph says that the hash function MUST be sha1 or sha2= 56. This is weird. First it provides no algorithm agility, so adding suppor= t for, say, SHA-3 would require a document that updates this one (section 2= .4 says so explicitly). Second, SHA2-256 is slower on 64-bit platforms than= SHA2-512, so right now some may prefer it. Third, in various locales, some= other hash function might be required, such as GOST-34.311-95. I would muc= h prefer that we referred to a registry of hash names ( perhaps this one ), and allow anything from there (notably, it doesn't solve the G= OST issue). There should be implementation advice advising support of SHA-1= and SHA-256, perhaps even calling them "mandatory to implement", but I don= 't think we need to require a new spec for updating a list of algorithms. I= t might also be good to advise on using the same hash algorithm that is use= d in the signature of the certificate, as the client would be sure to be ab= le to calculate the hash function (or it wouldn't be able to verify the cer= tificate signature. Some of the mandates in section 2 are mixed up. Section 2.2.1 second senten= ce has "=85 UAs MUST treat the host =85" - clearly a UA mandate. But this i= s part of section 2.2 ("Server Processing Model"). UA mandates should be s= omewhere under section 2.3 ("User Agent Processing Model"). Some cleaning u= p is needed there. Section 2.6 requires the same no-error-or-block behavior here as in HSTS. I= wonder if we need this level of strictness, or whether requiring this only= for errors involving the verification of pins. IOW, should this document r= equire that expired certificates cause a block, when such policy can and sh= ould be communicated via HSTS? Section 2.8 is about pinning self-signed (or self-issued) certificates. Sho= uld mention DANE (RFC 6698) type 2 or 3, because those are a more trust-wor= thy case than normal self-signed or self-issued certificates. Section 4 (security considerations) should have something about why it's wr= ong to use this header without HSTS. 3rd paragraph of section 1 says that u= sing them together is intended, so we should explain why. Section 5: yes, there are actions for IANA, as they allocate HTTP headers (= other than X-something). See the text from draft -14 of HSTS: 15. IANA Considerations Below is the Internet Assigned Numbers Authority (IANA) Permanent Message Header Field registration information per [RFC3864]. Header field name: Strict-Transport-Security Applicable protocol: HTTP Status: standard Author/Change controller: IETF Specification document(s): this one A more structural note: The introduction looks a little thin to me. The dra= ft dives into syntax in section 2 before the reader has any idea: * When and why you should want to add this header to your web server re= sponses. What is this defending against * Why you would want to pin an end-entity key, and alternatively why yo= u would want to ping something higher up the chain * What does it mean when there are multiple pins. AND? OR? The third question is answered later in the draft, but I think this informa= tion should go in the introduction. And one nit: * The upper-case SHOULD in the introduction seems inappropriate. RFC 21= 19 labels SHOULD (not sure this is even a pun) be used for cases of interop= erability or for preventing harm. Here, the use is the simple English "shou= ld", and doesn't mandate anything at all, so it ought to be lower-case: "We propose a new HTTP header to enable a web host to express to user agent= s (UAs) which Subject Public Key Info (SPKI) structure(s) UAs *should* expe= ct to be present in the host's certificate chain in future connections usin= g TLS (see [RFC5246]). Note: this review is with no hats. It is not part of some last-call process= . Please treat this as any other review on the list. Yoav --_000_F9AF39882F4345278AB3615D693C998Ccheckpointcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <71B8B5F9C9E40B48831079A7612B42B3@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable Hi

I have reviewed this draft, and here are some comments.

Section 2.1 last paragraph says that the hash function MUST be sha1 or= sha256. This is weird. First it provides no algorithm agility, so adding s= upport for, say, SHA-3 would require a document that updates this one (sect= ion 2.4 says so explicitly). Second, SHA2-256 is slower on 64-bit platforms than SHA2-512, so right now some ma= y prefer it. Third, in various locales, some other hash function might be r= equired, such as GOST-34.311-95. I would much prefer that we referred to a = registry of hash names ( perhaps this one ), and allow anything from there (notably, it doesn't solve t= he GOST issue). There should be implementation advice advising support of S= HA-1 and SHA-256, perhaps even calling them "mandatory to implement&qu= ot;, but I don't think we need to require a new spec for updating a list of algorithms. It might also be good to advise on= using the same hash algorithm that is used in the signature of the certifi= cate, as the client would be sure to be able to calculate the hash function= (or it wouldn't be able to verify the certificate signature.

Some of the mandates in section 2 are mixed up. Section 2.2.1 second s= entence has "=85 UAs MUST treat the host =85" - clearly a UA mand= ate. But this is part of section 2.2 ("Server Processing Model").  UA mandates should be somewhere under section 2= .3 ("User Agent Processing Model"). Some cleaning up is needed = there.

Section 2.6 requires the same no-error-or-block behavior here as in HS= TS. I wonder if we need this level of strictness, or whether requiring this= only for errors involving the verification of pins. IOW, should this docum= ent require that expired certificates cause a block, when such policy can and should be communicated via HSTS?

Section 2.8 is about pinning self-signed (or self-issued) certificates= . Should mention DANE (RFC 6698) type 2 or 3, because those are a more trus= t-worthy case than normal self-signed or self-issued certificates.

Section 4 (security considerations) should have something about why it= 's wrong to use this header without HSTS. 3rd paragraph of section 1 says t= hat using them together is intended, so we should explain why.

Section 5: yes, there are actions for IANA, as they allocate HTTP head= ers (other than X-something).  See the text from draft -14 of HSTS: 
15.  IANA Considerations


   Below is the Internet Assigned Numbers Authority (IANA) Permanent
   Message Header Field registration information per [RFC3864].

     Header field name:           Strict-Transport-Security
     Applicable protocol:         HTTP
     Status:                      standard
     Author/Change controller:    IETF
     Specification document(s):   this one

A more structural note: The introduction looks a little thin to me. Th= e draft dives into syntax in section 2 before the reader has any idea:
  • When and why you should want to add this header to your web server resp= onses. What is this defending against
  • Why you would want to pin an = end-entity key, and alternatively why you would want to ping something high= er up the chain
  • What does it mean when there are multiple pins. AND= ? OR?

The third question is answered later in the draft, but I think this in= formation should go in the introduction.


And one nit:
  • The upper-case SHOULD in the introduction seems inappropriate. RFC 2119= labels SHOULD (not sure this is even a pun) be used for cases of interoper= ability or for preventing harm. Here, the use is the simple English "s= hould", and doesn't mandate anything at all, so it ought to be lower-case:
    "We propose a new HTTP header to enable a web host to express to user = agents (UAs) which Subject Public Key Info (SPKI) structure(s) UAs *should*= expect to be present in the host's certificate chain in future connections= using TLS (see [RFC5246]).

Note: this review is with no hats. It is not part of some last-call pr= ocess. Please treat this as any other review on the list.

Yoav

--_000_F9AF39882F4345278AB3615D693C998Ccheckpointcom_-- From ynir@checkpoint.com Mon Mar 18 05:14: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 D5D9D21F8D03 for ; Mon, 18 Mar 2013 05:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.392 X-Spam-Level: X-Spam-Status: No, score=-10.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 xf4S8aCg10Ma for ; Mon, 18 Mar 2013 05:14:55 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C8BCF21F8717 for ; Mon, 18 Mar 2013 05:14:54 -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 r2ICEq6L004271; Mon, 18 Mar 2013 14:14:52 +0200 X-CheckPoint: {51470426-1-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Mon, 18 Mar 2013 14:14:52 +0200 From: Yoav Nir To: Phillip Hallam-Baker Thread-Topic: [websec] Session Continuation = Session Bound State? Thread-Index: AQHOIGcFEBuYGjBbAkmU2taz3PSEppirQgsA Date: Mon, 18 Mar 2013 12:14:50 +0000 Message-ID: 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.24.195] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: websec Subject: Re: [websec] Session Continuation = Session Bound State? 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, 18 Mar 2013 12:14:56 -0000 I'm kind of partial to "session management" On Mar 13, 2013, at 11:49 PM, Phillip Hallam-Baker wrote= : > The main substantive query that seemed to be raised in the meeting was > what we are going to call this session continuation thing. I am not > that worried about confusion with HTTP-Auth. Folk who know, know. >=20 > But one of the objectives here is to replace cookies. So choosing a > name that positions the spec as a successor to authentication cookies > is actually quite important. >=20 >=20 > How about Session Bound State as the term of art? >=20 > --=20 > Website: http://hallambaker.com/ From tobias.gondrom@gondrom.org Tue Mar 19 01:58: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 E0A4521F88E2 for ; Tue, 19 Mar 2013 01:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.212 X-Spam-Level: X-Spam-Status: No, score=-95.212 tagged_above=-999 required=5 tests=[AWL=0.151, 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 4LY4-4ZORrBt for ; Tue, 19 Mar 2013 01:58: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 BB8BC21F88CA for ; Tue, 19 Mar 2013 01:58:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=MKsPgR7/+ic1k+ynNNcc3vt3vhFeAU3PJMoPHb/7PbcNoVfFx+/4AtufdmJJyDIDRHsPgoUNpfDy04uvzVdKLr/49s4RV9N5+jE396lkXVw/MvC4ousgMWVkajz9Wuc/; 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 29974 invoked from network); 19 Mar 2013 09:58:33 +0100 Received: from d1-162-57-143-118-on-nets.com (HELO ?10.8.18.138?) (118.143.57.162) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Mar 2013 09:58:33 +0100 Message-ID: <514828B5.9090604@gondrom.org> Date: Tue, 19 Mar 2013 16:58:29 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: ynir@checkpoint.com References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] Session Continuation = Session Bound State? 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, 19 Mar 2013 08:58:36 -0000 Session Management sounds good to me. (And we could change the name anytime over the evolution of the draft.) Best regards, Tobias On 18/03/13 20:14, Yoav Nir wrote: > I'm kind of partial to "session management" > > On Mar 13, 2013, at 11:49 PM, Phillip Hallam-Baker wrote: > >> The main substantive query that seemed to be raised in the meeting was >> what we are going to call this session continuation thing. I am not >> that worried about confusion with HTTP-Auth. Folk who know, know. >> >> But one of the objectives here is to replace cookies. So choosing a >> name that positions the spec as a successor to authentication cookies >> is actually quite important. >> >> >> How about Session Bound State as the term of art? >> >> -- >> Website: http://hallambaker.com/ > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From hhalpin@w3.org Tue Mar 19 07:21: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 5087C21F8A8F for ; Tue, 19 Mar 2013 07:21: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 95B4V3vXa9sc for ; Tue, 19 Mar 2013 07:21:12 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id D783521F8A84 for ; Tue, 19 Mar 2013 07:21:12 -0700 (PDT) Received: from men75-11-88-175-104-179.fbx.proxad.net ([88.175.104.179] helo=[192.168.1.34]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UHxPb-0005Y8-Nv; Tue, 19 Mar 2013 10:21:12 -0400 Message-ID: <51487450.2060707@w3.org> Date: Tue, 19 Mar 2013 15:21:04 +0100 From: Harry Halpin User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: websec Subject: Re: [websec] Session Continuation = Session Bound State? 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, 19 Mar 2013 14:21:13 -0000 On 03/14/2013 04:49 AM, Phillip Hallam-Baker wrote: > The main substantive query that seemed to be raised in the meeting was > what we are going to call this session continuation thing. I am not > that worried about confusion with HTTP-Auth. Folk who know, know. > > But one of the objectives here is to replace cookies. So choosing a > name that positions the spec as a successor to authentication cookies > is actually quite important. > > > How about Session Bound State as the term of art? > For those of who weren't at the meeting, can we get a summary or a pointer? cheers, harry From nico@cryptonector.com Tue Mar 19 08:21: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 B32E821F8D34 for ; Tue, 19 Mar 2013 08:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 CtMAcxzat5uG for ; Tue, 19 Mar 2013 08:21:19 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id F1F7C21F8D5D for ; Tue, 19 Mar 2013 08:21:18 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 69DF17E4072 for ; Tue, 19 Mar 2013 08:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=YDDQqRWp1me2dtdryMOJ Hs33iDo=; b=ZhynC9Ih1XI90fdT3Ye3ZvfoKnEowjGNPscUJdL2QfYoYBGrP5yt JgIK78kbImQLYMOIKE3qVEJBZIYQoAU/Gby3Bae1Jkete+wsL3dxcFxtseOpxNxS jb5ofjxUF+0rji1Y7UMyf5ZwyJROo1dIW1r4sO7SlTlW6SfNQt4zaJc= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id 3FAAC7E4058 for ; Tue, 19 Mar 2013 08:21:16 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hm14so4088993wib.3 for ; Tue, 19 Mar 2013 08:21:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.108.3 with SMTP id hg3mr3891706wib.33.1363706474972; Tue, 19 Mar 2013 08:21:14 -0700 (PDT) Received: by 10.217.113.198 with HTTP; Tue, 19 Mar 2013 08:21:14 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Mar 2013 10:21:14 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Cc: websec Subject: Re: [websec] Session Continuation = Session Bound State? 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, 19 Mar 2013 15:21:19 -0000 On Mon, Mar 18, 2013 at 7:14 AM, Yoav Nir wrote: > I'm kind of partial to "session management" I am too, but am afraid that that can lead to confusion, since we're only dealing with establishment, use, and synchronous destruction of sessions, not any other aspect of session management (e.g., listing active sessions, administrative session destruction, setting of session parameter negotiation parameters, ...). I've liked both terms Phillip has proposed so far: Session Continuation, and: >> How about Session Bound State as the term of art? I'd also be happy with: Session Layer. (And: Cookie Slayer, and any other punny names we might think of :) Nico -- From ynir@checkpoint.com Tue Mar 19 19:44: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 5557B21F8F0F for ; Tue, 19 Mar 2013 19:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.406 X-Spam-Level: X-Spam-Status: No, score=-10.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 CfNXcecO7qM7 for ; Tue, 19 Mar 2013 19:44:57 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB1621F8455 for ; Tue, 19 Mar 2013 19:44: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 r2K2it4S030928; Wed, 20 Mar 2013 04:44:55 +0200 X-CheckPoint: {5149217A-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Wed, 20 Mar 2013 04:44:55 +0200 From: Yoav Nir To: Harry Halpin , websec Thread-Topic: Starting work on Session Continuation/Bound State/Management (was: Session Continuation = Session Bound State?) Thread-Index: AQHOJRTmB6HrN5Hlik+ysGrhUrSkBQ== Date: Wed, 20 Mar 2013 02:44:54 +0000 Message-ID: References: <51487450.2060707@w3.org> In-Reply-To: <51487450.2060707@w3.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.169] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [websec] Starting work on Session Continuation/Bound State/Management (was: Session Continuation = Session Bound State?) 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, 20 Mar 2013 02:44:58 -0000 Hi Harry. On Mar 19, 2013, at 10:21 AM, Harry Halpin wrote: > On 03/14/2013 04:49 AM, Phillip Hallam-Baker wrote: >> The main substantive query that seemed to be raised in the meeting was >> what we are going to call this session continuation thing. I am not >> that worried about confusion with HTTP-Auth. Folk who know, know. >>=20 >> But one of the objectives here is to replace cookies. So choosing a >> name that positions the spec as a successor to authentication cookies >> is actually quite important. >>=20 >>=20 >> How about Session Bound State as the term of art? >>=20 >=20 > For those of who weren't at the meeting, can we get a summary or a pointe= r? You can get both. There's the presentation that Phillip gave at the meeting: http://www.ietf.= org/proceedings/86/slides/slides-86-websec-3.pdf Also, there's Nico's draft: http://tools.ietf.org/html/draft-williams-webse= c-session-continue-prob To summarize, the problem we are trying to solve, is that the current metho= d of keeping sessions in HTTP through the use of session cookies has a lot = of drawbacks: 1. Cookies are not cryptographically bound to authentication, so there are= many opportunities for an attacker to insert itself in the middle. 2. Cookies are bearer tokens, which makes them attractive targets. Just in= the last 18 months we've seen three attacks that recover the cookies even = with TLS (BEAST, CRIME, Lucky-13) 3. The rules for cookie usage are such that static and active content on o= ne page can make requests on the user's behalf to another site, and have th= ose requests authenticated by the user's cookie. 4. Depending on cookie format, either the client or the server, but never = both, can destroy the state, effectively terminating the session. It's the = "not both" that is the issue. So Nico and a design team wrote the above-mentioned draft that should have = a problem statement and requirements. This is an initial draft and still re= quires much work. We are asking the working group to review this and post o= pinions to the list. If the review is as positive as the sentiment in the r= oom was, we will adopt this and make this a working group document. For now= , we're requesting reviews and textual suggestions. Yoav From rlb@ipv.sx Wed Mar 20 07:24: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 7DF0721F8FCD for ; Wed, 20 Mar 2013 07:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.472, 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 M9XIIJHJ8bnw for ; Wed, 20 Mar 2013 07:24:16 -0700 (PDT) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7E55E21F8FAB for ; Wed, 20 Mar 2013 07:24:14 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id j1so1813941oag.21 for ; Wed, 20 Mar 2013 07:24:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=hL54/CQNeX1twVRCLZp5EKtUNLJbT+0UvUfp+EmJzTc=; b=QMovbUdoQHk6k8jVUhmVKmIer2809n+ZlqbGYCXtxKZ28JUlOCavjlbSR/rzI5Lqd6 dzTXSAjIHvCDYCpgVXR8i8LSzwtoPtZAbiNmm2HV1oF2HYe9Z9i2KEQvWc33JLfs2P6d OaKj/jlHPU1YfsNXyHu53GKJ3Lo1ITB291+U0/06mLdVGCjVxUg/rW2G4ofDFJjJQuNV 3NsT0oPzY8ZdSS3bUIv/mlV+HAHhSmY3yFTbMGXT5dwZ7WTygx6A6/NUleXEJ0Ml09xc Ntwa708ir4mTIBcJ3NQbZu8q36wUtbPH9BYszw9U25Zx0mm8tjXsZ8fkCgrHvfwvkcfJ J1Qw== MIME-Version: 1.0 X-Received: by 10.60.170.140 with SMTP id am12mr4061324oec.125.1363789453967; Wed, 20 Mar 2013 07:24:13 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Wed, 20 Mar 2013 07:24:13 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: References: Date: Wed, 20 Mar 2013 10:24:13 -0400 Message-ID: From: Richard Barnes To: Nico Williams Content-Type: multipart/alternative; boundary=bcaec54b4812f429af04d85bf92d X-Gm-Message-State: ALoCoQmyGnuEAQ47MAVr0yqtXSByNdm3gLRHcHgMzlljDzi/55RAYRTk7WN/2jgxe0mjsKBaoplK Cc: websec Subject: Re: [websec] Session Continuation = Session Bound State? 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, 20 Mar 2013 14:24:17 -0000 --bcaec54b4812f429af04d85bf92d Content-Type: text/plain; charset=ISO-8859-1 Adam Barth proposed "cake" a little while back. On Tue, Mar 19, 2013 at 11:21 AM, Nico Williams wrote: > On Mon, Mar 18, 2013 at 7:14 AM, Yoav Nir wrote: > > I'm kind of partial to "session management" > > I am too, but am afraid that that can lead to confusion, since we're > only dealing with establishment, use, and synchronous destruction of > sessions, not any other aspect of session management (e.g., listing > active sessions, administrative session destruction, setting of > session parameter negotiation parameters, ...). > > I've liked both terms Phillip has proposed so far: Session Continuation, > and: > > >> How about Session Bound State as the term of art? > > I'd also be happy with: Session Layer. (And: Cookie Slayer, and any > other punny names we might think of :) > > Nico > -- > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > --bcaec54b4812f429af04d85bf92d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Adam Barth proposed "cake" a little while back.




On Tue, Mar 19, 2013 at 11:21 AM, Nico Williams <nico@cryptonector.com= > wrote:
On Mon, Mar 18, 2013 at 7:14 AM, Yoav Nir <ynir@checkpoint.com> wrote:
> I'm kind of partial to "session management"

I am too, but am afraid that that can lead to confusion, since we'= ;re
only dealing with establishment, use, and synchronous destruction of
sessions, not any other aspect of session management (e.g., listing
active sessions, administrative session destruction, setting of
session parameter negotiation parameters, ...).

I've liked both terms Phillip has proposed so far: Session Continuation= , and:

>> How about Session Bound State as the term of art?

I'd also be happy with: =A0Session Layer. =A0(And: Cookie Slayer,= and any
other punny names we might think of :)

Nico
--
___________________________________= ____________
websec mailing list
websec@ietf.org
= https://www.ietf.org/mailman/listinfo/websec

--bcaec54b4812f429af04d85bf92d-- From trac+websec@trac.tools.ietf.org Fri Mar 22 14:36: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 EE6AE21F943C for ; Fri, 22 Mar 2013 14:36: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=[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 d3mfUUYOWSbO for ; Fri, 22 Mar 2013 14:36: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 DED5A21F9439 for ; Fri, 22 Mar 2013 14:36:03 -0700 (PDT) Received: from localhost ([127.0.0.1]:38788 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UJ9d5-0005gl-3b; Fri, 22 Mar 2013 22:36:03 +0100 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: palmer@google.com X-Trac-Project: websec Date: Fri, 22 Mar 2013 21:36:03 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/websec/trac/ticket/57 Message-ID: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> X-Trac-Ticket-ID: 57 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, sleevi@google.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 Cc: websec@ietf.org, sleevi@google.com Subject: [websec] #57: Re-add an upper limit to max-age 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: Fri, 22 Mar 2013 21:36:17 -0000 #57: Re-add an upper limit to max-age At IETF 86, it was decided that there should be an upper limit to the max- age directive -- --------------------------------+------------------------------- Reporter: palmer@google.com | Owner: palmer@google.com Type: defect | Status: new Priority: major | Milestone: Component: key-pinning | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Fri Mar 22 14:39: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 272A921F9469 for ; Fri, 22 Mar 2013 14:39:58 -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 sq97bURtwJ7U for ; Fri, 22 Mar 2013 14:39:57 -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 6C5D021F9465 for ; Fri, 22 Mar 2013 14:39:57 -0700 (PDT) Received: from localhost ([127.0.0.1]:38936 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UJ9gp-00006M-IE; Fri, 22 Mar 2013 22:39:55 +0100 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: palmer@google.com X-Trac-Project: websec Date: Fri, 22 Mar 2013 21:39:55 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/57#comment:1 Message-ID: <073.92e203ac2ffbca6a9b6ecd285f8d0e00@trac.tools.ietf.org> References: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, sleevi@google.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 Cc: websec@ietf.org, sleevi@google.com Subject: Re: [websec] #57: Re-add an upper limit to max-age 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: Fri, 22 Mar 2013 21:39:58 -0000 #57: Re-add an upper limit to max-age Comment (by palmer@google.com): Rather, it was decided that there should be implementation guidance for setting an upper limit, including discussing the security considerations /trade-offs of high vs. low maximum max-age values. -- --------------------------------+-------------------------------- Reporter: palmer@google.com | Owner: palmer@google.com Type: defect | Status: new Priority: major | Milestone: Component: key-pinning | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+-------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Fri Mar 22 15:16: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 E4C5321F946B for ; Fri, 22 Mar 2013 15:16:19 -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 FAkcDYN6pm50 for ; Fri, 22 Mar 2013 15:16:19 -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 4B43A21F9468 for ; Fri, 22 Mar 2013 15:16:19 -0700 (PDT) Received: from localhost ([127.0.0.1]:40949 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UJAG1-0004CD-FL; Fri, 22 Mar 2013 23:16:17 +0100 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: palmer@google.com X-Trac-Project: websec Date: Fri, 22 Mar 2013 22:16:17 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/websec/trac/ticket/57#comment:2 Message-ID: <073.d5e04ed45c6576b8bffb306ee12506c0@trac.tools.ietf.org> References: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, sleevi@google.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 Cc: websec@ietf.org, sleevi@google.com Subject: Re: [websec] #57: Re-add an upper limit to max-age 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: Fri, 22 Mar 2013 22:16:20 -0000 #57: Re-add an upper limit to max-age Comment (by palmer@google.com): I have added language discussing the issue to the latest working copy of the draft at https://code.google.com/p/key-pinning-draft/source/browse /draft-ietf-websec-key-pinning.xml. -- --------------------------------+-------------------------------- Reporter: palmer@google.com | Owner: palmer@google.com Type: defect | Status: new Priority: major | Milestone: Component: key-pinning | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+-------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Fri Mar 22 15:21:41 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 4F8DA21F9470 for ; Fri, 22 Mar 2013 15:21:41 -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 ZwQuvyQQM3ed for ; Fri, 22 Mar 2013 15:21:40 -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 9570F21F9468 for ; Fri, 22 Mar 2013 15:21:40 -0700 (PDT) Received: from localhost ([127.0.0.1]:41096 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UJALD-0004J1-L3; Fri, 22 Mar 2013 23:21:39 +0100 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: palmer@google.com X-Trac-Project: websec Date: Fri, 22 Mar 2013 22:21:39 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/56#comment:2 Message-ID: <073.01d29ebb0472d75942e685ff4ea1bf03@trac.tools.ietf.org> References: <058.f40b082eeef2f8676dd01f9fbb11ca5b@trac.tools.ietf.org> X-Trac-Ticket-ID: 56 In-Reply-To: <058.f40b082eeef2f8676dd01f9fbb11ca5b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, sleevi@google.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 Cc: websec@ietf.org, sleevi@google.com Subject: Re: [websec] #56: Specify includeSubdomains directive for HPKP 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: Fri, 22 Mar 2013 22:21:41 -0000 #56: Specify includeSubdomains directive for HPKP Comment (by palmer@google.com): TODO: Discuss the problem that, given that we prefer (2), Pinned Host operators will have a problem if UAs by chance happen to visit Google.com first, and then second try to visit WWW.Google.com. Due to includeSubdomains, the pins A and B will take effect, and Pin Validation will fail, *before the UA has a chance to note the pin C for WWW.Google.com*. Host operators SHOULD take this problem into account when deploying Pinned Hosts. -- -------------------------------+-------------------------------- Reporter: palmer@google.com | Owner: palmer@google.com Type: defect | Status: assigned Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Resolution: Keywords: includeSubdomains | -------------------------------+-------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Fri Mar 22 15:47: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 CCBB821F9146 for ; Fri, 22 Mar 2013 15:47:55 -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 I6Q0BPPPmome for ; Fri, 22 Mar 2013 15:47:55 -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 1FEA421F9138 for ; Fri, 22 Mar 2013 15:47:54 -0700 (PDT) Received: from localhost ([127.0.0.1]:41788 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UJAkb-0004Zp-5t; Fri, 22 Mar 2013 23:47:53 +0100 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: palmer@google.com X-Trac-Project: websec Date: Fri, 22 Mar 2013 22:47:53 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/websec/trac/ticket/56#comment:3 Message-ID: <073.ab8eb5d38166047c5429d8354762a5fd@trac.tools.ietf.org> References: <058.f40b082eeef2f8676dd01f9fbb11ca5b@trac.tools.ietf.org> X-Trac-Ticket-ID: 56 In-Reply-To: <058.f40b082eeef2f8676dd01f9fbb11ca5b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, sleevi@google.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 Cc: websec@ietf.org, sleevi@google.com Subject: Re: [websec] #56: Specify includeSubdomains directive for HPKP 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: Fri, 22 Mar 2013 22:47:55 -0000 #56: Specify includeSubdomains directive for HPKP Comment (by palmer@google.com): I have added language to the working copy of the draft (https://code.google.com/p/key-pinning-draft/source/browse/draft-ietf- websec-key-pinning.xml) in the Security Considerations section. -- -------------------------------+-------------------------------- Reporter: palmer@google.com | Owner: palmer@google.com Type: defect | Status: assigned Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Resolution: Keywords: includeSubdomains | -------------------------------+-------------------------------- Ticket URL: websec From trevp@trevp.net Fri Mar 22 16:07: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 C79D321F85A4 for ; Fri, 22 Mar 2013 16:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJ6BzUVY9mg5 for ; Fri, 22 Mar 2013 16:07:37 -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 1060221F85A2 for ; Fri, 22 Mar 2013 16:07:36 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id fm10so663817wgb.21 for ; Fri, 22 Mar 2013 16:07:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=33wMwJQshDmrfutRcUOmtNUBxdYYZmfWRjEZbXyAHr4=; b=MsflyUIvAUStzajF8aLZism9jZ5uULQxlmMy4LwsFy3PXqWbummBzfeYzNc4m17pKZ bsRJTZyfs7/cc1Clrbg82LsOIYCMkC3wXbqKeuI4GAfUYNI/emBct3seNbh1qGTjEqCX vjRndQR3V3i9pLsDUKd07ZKWKIgLzuBmSPIQOCRfAWbl5kDfTscaMVQbZbHm18udSnEf IIdPPioJwTyJVw+FHlFwLvPef51Z39sktHlQF9M2EjlwXOvXzEfVsJhX1Vg6mUslo5T8 31pru/L+09KbSc6IFV73xKMMySp0Qq2SM1mnYckPOS3H0FJrWwFohAAb2ivwkz1JI1tW zpJQ== MIME-Version: 1.0 X-Received: by 10.180.87.170 with SMTP id az10mr5986263wib.3.1363993656154; Fri, 22 Mar 2013 16:07:36 -0700 (PDT) Received: by 10.216.112.7 with HTTP; Fri, 22 Mar 2013 16:07:36 -0700 (PDT) X-Originating-IP: [166.137.187.253] In-Reply-To: <073.92e203ac2ffbca6a9b6ecd285f8d0e00@trac.tools.ietf.org> References: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> <073.92e203ac2ffbca6a9b6ecd285f8d0e00@trac.tools.ietf.org> Date: Fri, 22 Mar 2013 16:07:36 -0700 Message-ID: From: Trevor Perrin To: websec issue tracker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnizfzRQdtmI07rQhPp96kHNp5YCHUirmyOu+ASC8C41oR4Td11IsiAPGdcX0NYka4G+d3Y Cc: websec@ietf.org, sleevi@google.com Subject: Re: [websec] #57: Re-add an upper limit to max-age 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, 22 Mar 2013 23:07:37 -0000 On Fri, Mar 22, 2013 at 2:39 PM, websec issue tracker wrote: > #57: Re-add an upper limit to max-age > > > Comment (by palmer@google.com): > > Rather, it was decided that there should be implementation guidance for > setting an upper limit, including discussing the security considerations > /trade-offs of high vs. low maximum max-age values. So this maximum is a "local policy" decided by the UA? It might be good to also have a spec-mandated maximum. There are cases where you (a domain owner) might have unknown pins or bad pins. For example: - you purchased a domain name from someone - the domain name was victimized by domain hijacking or domain squatting - you misconfigured pins for your domain If there's no spec-mandated maximum, then there's no point in time at which all old pins are guaranteed to have been expired, and you can start referring people to this domain safely. With a spec maximum (say 30 days), then you have a clear reference point to plan around. Trevor From jbonneau@gmail.com Fri Mar 22 16:36: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 D98C421F8C11 for ; Fri, 22 Mar 2013 16:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 pwnaM7uWf6dL for ; Fri, 22 Mar 2013 16:36:44 -0700 (PDT) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id D3B2D21F8936 for ; Fri, 22 Mar 2013 16:36:39 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id a11so2676148qen.33 for ; Fri, 22 Mar 2013 16:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=LCHOXWdj59hcQvgv5/m+i9kIcIlyol6wAKwSWBvjJxk=; b=clsfHGUJRrn5j4NSq3XUK6doxf0u++90KLqB3yzmoYiKeMHn7YQ/jQ1IH8H6C+Dj0n 2i97/PwKRO/TzcMiS/YlVAu6lVgoqXp024W9PGldipxzTIVgJM87JNd6uzIRxEnMOKrY wh9fsJekMla1Dpec/uaKE8F/NyIwRbO/CFa3pQVdOd4fPo+oJz5uBAZ8fmSadm8sh2Z2 lQRb9aNDh2mtyBhCRvEE22aDefWJtIGolBbI3apzsizeR0w7Gv165/Gs7XuYgBLZRKiE WwJRP1yu88f8VolwcENTRpmPu2TjQSrbrA2aRna4VHV8JniL01rUO9VR2rTWqFQqAxPu 8ZGQ== X-Received: by 10.49.64.72 with SMTP id m8mr1436424qes.51.1363995399360; Fri, 22 Mar 2013 16:36:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.6.202 with HTTP; Fri, 22 Mar 2013 16:36:19 -0700 (PDT) In-Reply-To: References: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> <073.92e203ac2ffbca6a9b6ecd285f8d0e00@trac.tools.ietf.org> From: Joseph Bonneau Date: Fri, 22 Mar 2013 19:36:19 -0400 Message-ID: To: Trevor Perrin Content-Type: text/plain; charset=UTF-8 Cc: websec issue tracker , websec@ietf.org, sleevi@google.com Subject: Re: [websec] #57: Re-add an upper limit to max-age 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, 22 Mar 2013 23:36:45 -0000 On Fri, Mar 22, 2013 at 7:07 PM, Trevor Perrin wrote: > With a spec maximum (say 30 days), then you have a clear reference > point to plan around. Agreed. I have some stats I've been looking at from Google's web crawls about HSTS headers. Out of 12853 hosts I observed setting HSTS, 53% set of a max-age of 1 year. After that it's 15% 30 days, 12% 180 days, 10% 1 day, and a smattering of other choices (with a few large hosts like Twitter setting very long-lived max-age). These are only a rough upper bound on the max-age values that would be set for pins, but it seems a substantial number of hosts would request longer than 30 days, while 1 year will support most likely use cases, so we should probably land somewhere between those two points. The follow-on question is, if UAs allow max-age of 1 year, will there need to be a revocation method to deal with some of the cases that Trevor highlighted? From ynir@checkpoint.com Fri Mar 22 19:13:41 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 5CDA621F8E7F for ; Fri, 22 Mar 2013 19:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.454 X-Spam-Level: X-Spam-Status: No, score=-10.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 bszh6Bnv3Khj for ; Fri, 22 Mar 2013 19:13:40 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 69CF621F8E7E for ; Fri, 22 Mar 2013 19:13:40 -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 r2N2DJoN013629; Sat, 23 Mar 2013 04:13:19 +0200 X-CheckPoint: {514D0E66-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Sat, 23 Mar 2013 04:13:19 +0200 From: Yoav Nir To: Joseph Bonneau Thread-Topic: [websec] #57: Re-add an upper limit to max-age Thread-Index: AQHOJ0X4m4jM1OHiCUi5AgAOGVjbxZiyNAIAgAAIBoCAACvZgA== Date: Sat, 23 Mar 2013 02:13:18 +0000 Message-ID: References: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> <073.92e203ac2ffbca6a9b6ecd285f8d0e00@trac.tools.ietf.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.41] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <609113009BA92D4690E8CDC657275E7B@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , websec issue tracker , "" Subject: Re: [websec] #57: Re-add an upper limit to max-age 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, 23 Mar 2013 02:13:41 -0000 On Mar 22, 2013, at 7:36 PM, Joseph Bonneau wrote: > On Fri, Mar 22, 2013 at 7:07 PM, Trevor Perrin wrote: >> With a spec maximum (say 30 days), then you have a clear reference >> point to plan around. >=20 > Agreed. >=20 > I have some stats I've been looking at from Google's web crawls about > HSTS headers. Out of 12853 hosts I observed setting HSTS, 53% set of a > max-age of 1 year. After that it's 15% 30 days, 12% 180 days, 10% 1 > day, and a smattering of other choices (with a few large hosts like > Twitter setting very long-lived max-age). As Ekr said in the meeting, there is a big difference here between HSTS and= HPKP. It doesn't matter if Paypal or some bank advertises HSTS for a milli= on years. It's not likely that someone who has declared a policy for always= using secure transport will suddenly switch to non-secure transport. They = might stop advertising HSTS, but they're not likely to stop insisting on TL= S use. OTOH a particular public key might be replaced because of switching certifi= cate vendors, because auditors don't like that key length any more, or beca= use your certificate vendor has decided that ECC is the way to go. Pinning = something that has an expiry date for an unlimited time could be a problem. Something to consider is that if the max-age time is shorter than the time = between accesses to the site, the security of this mechanism is lost. If ei= ther the draft or the UA sets an upper limit of 30 days, then HKPK won't wo= rk for pub.ietf.org. This is a site that I only use from one week before an= IETF meeting to one week following it. In between there are a little over = three months where I don't use the site at all. So it would make sense for = the site operator to set a max-age of 4 months. That limit may be inappropr= iate for web mail or social media, but even those might be accessed from di= fferent UAs at different times. For example, I might use my home computer f= or a social media site while I'm at home, but use a smart phone or a laptop= for the same site when I'm away from home.=20 I understand Trevor's issue. Does it make a difference to a site operator w= hether the site is partially bricked by bad pins for 30 days or 365 days? Yoav From ynir@checkpoint.com Fri Mar 22 19:15:41 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 B6C1521F8E7F for ; Fri, 22 Mar 2013 19:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.461 X-Spam-Level: X-Spam-Status: No, score=-10.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 sg5Yg0Uk-URk for ; Fri, 22 Mar 2013 19:15:40 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 009B021F8E7E for ; Fri, 22 Mar 2013 19:15:39 -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 r2N2FHVJ013790; Sat, 23 Mar 2013 04:15:17 +0200 X-CheckPoint: {514D0EDC-1-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Sat, 23 Mar 2013 04:15:17 +0200 From: Yoav Nir To: websec issue tracker Thread-Topic: [websec] #56: Specify includeSubdomains directive for HPKP Thread-Index: AQHOJ09S5/focKvZqky7mHmoEP/1jJiyaFkA Date: Sat, 23 Mar 2013 02:15:17 +0000 Message-ID: References: <058.f40b082eeef2f8676dd01f9fbb11ca5b@trac.tools.ietf.org> <073.ab8eb5d38166047c5429d8354762a5fd@trac.tools.ietf.org> In-Reply-To: <073.ab8eb5d38166047c5429d8354762a5fd@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.41] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <81305F921DD5164B8C32F6BD9E0CC348@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [websec] #56: Specify includeSubdomains directive for HPKP 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, 23 Mar 2013 02:15:41 -0000 That text works for me.=20 On Mar 22, 2013, at 6:47 PM, websec issue tracker wrote: > #56: Specify includeSubdomains directive for HPKP >=20 >=20 > Comment (by palmer@google.com): >=20 > I have added language to the working copy of the draft > (https://code.google.com/p/key-pinning-draft/source/browse/draft-ietf- > websec-key-pinning.xml) in the Security Considerations section. >=20 > --=20 > -------------------------------+-------------------------------- > Reporter: palmer@google.com | Owner: palmer@google.com > Type: defect | Status: assigned > Priority: major | Milestone: > Component: key-pinning | Version: > Severity: - | Resolution: > Keywords: includeSubdomains | > -------------------------------+-------------------------------- >=20 > Ticket URL: > websec >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec >=20 > Email secured by Check Point From tobias.gondrom@gondrom.org Sat Mar 23 05:38: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 88A8121F8A3F for ; Sat, 23 Mar 2013 05:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.262 X-Spam-Level: X-Spam-Status: No, score=-95.262 tagged_above=-999 required=5 tests=[AWL=0.100, 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 oARZpPc44F5u for ; Sat, 23 Mar 2013 05:38:04 -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 5C44E21F8A0C for ; Sat, 23 Mar 2013 05:38:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=JNtpkNyB00FioaDcf9OJhg5Hpfd8P+4atFe8fzEuKPyuQlmE9JyWtSw2QnTYgwPBLCVkwG/zmfjVG0X92oXBPX8cFjfONF/857Sh21Y2YzrySUeEP5veOeMWBz5juxPT; 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 15987 invoked from network); 23 Mar 2013 13:38:03 +0100 Received: from d1-162-57-143-118-on-nets.com (HELO ?10.8.18.138?) (118.143.57.162) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 23 Mar 2013 13:38:02 +0100 Message-ID: <514DA21C.8050802@gondrom.org> Date: Sat, 23 Mar 2013 20:37:48 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: websec@ietf.org References: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> <073.92e203ac2ffbca6a9b6ecd285f8d0e00@trac.tools.ietf.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [websec] #57: Re-add an upper limit to max-age 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, 23 Mar 2013 12:38:05 -0000 I agree with Yoav's comment. Am not 100% sure on this, as I don't know the frequency of "self-bricking" due to the reasons described by Trevor, but feel that 30 days is too short for protection of rare use users. Don't forget, we have not solved the boot-strapping issue for HSTS and HKPK. So if the max-age is too low, we basically leave all infrequent users unprotected. (and I guess there are quite a number of important sites that people would only go to only once in a while but not for sure every 30 days). If I would have to balance between "self-inflicted bricking" (due to mis-config, bad business deals, weak security, etc.) and user protection, my vote would go for user protection. So if we need a max-age, I would probably prefer a longer time, e.g. a max-age of 1 year. Best regards, Tobias On 23/03/13 10:13, Yoav Nir wrote: > On Mar 22, 2013, at 7:36 PM, Joseph Bonneau wrote: > >> On Fri, Mar 22, 2013 at 7:07 PM, Trevor Perrin wrote: >>> With a spec maximum (say 30 days), then you have a clear reference >>> point to plan around. >> Agreed. >> >> I have some stats I've been looking at from Google's web crawls about >> HSTS headers. Out of 12853 hosts I observed setting HSTS, 53% set of a >> max-age of 1 year. After that it's 15% 30 days, 12% 180 days, 10% 1 >> day, and a smattering of other choices (with a few large hosts like >> Twitter setting very long-lived max-age). > As Ekr said in the meeting, there is a big difference here between HSTS and HPKP. It doesn't matter if Paypal or some bank advertises HSTS for a million years. It's not likely that someone who has declared a policy for always using secure transport will suddenly switch to non-secure transport. They might stop advertising HSTS, but they're not likely to stop insisting on TLS use. > > OTOH a particular public key might be replaced because of switching certificate vendors, because auditors don't like that key length any more, or because your certificate vendor has decided that ECC is the way to go. Pinning something that has an expiry date for an unlimited time could be a problem. > > Something to consider is that if the max-age time is shorter than the time between accesses to the site, the security of this mechanism is lost. If either the draft or the UA sets an upper limit of 30 days, then HKPK won't work for pub.ietf.org. This is a site that I only use from one week before an IETF meeting to one week following it. In between there are a little over three months where I don't use the site at all. So it would make sense for the site operator to set a max-age of 4 months. That limit may be inappropriate for web mail or social media, but even those might be accessed from different UAs at different times. For example, I might use my home computer for a social media site while I'm at home, but use a smart phone or a laptop for the same site when I'm away from home. > > I understand Trevor's issue. Does it make a difference to a site operator whether the site is partially bricked by bad pins for 30 days or 365 days? > > Yoav > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From trevp@trevp.net Sat Mar 23 15:19: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 E0BBA21F8BDD for ; Sat, 23 Mar 2013 15:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.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 hysI-1m2IiGR for ; Sat, 23 Mar 2013 15:19:32 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E0F5C21F8BDB for ; Sat, 23 Mar 2013 15:19:31 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id ez12so885725wid.6 for ; Sat, 23 Mar 2013 15:19:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=RsF0Rx459zwlQiHXk46NvX4E9GdfJ36RUyugifS5Hbk=; b=ffDZb4Q2p9AvKuHuia6Nu/VxE+/7KNW7mMtquI+TY8WXoS45p7VzCevpX3/fomTNDH eg2xFbzw+ybk7kh4cPf4OeuTTsmZSlOUhXkBW5r3gsML0MFycwo+1uE9ORGjQU5WmcF9 MXlSg6QVbZK3qDHk5ONJyOYj/0Cq+OMjpVT8cIk151bx6kkZoJdMOmzfqvd5PC+78FDE Z6eZ+GfGZm/eREebG6VthTf523N2IO9F1SDIDIrgY2XkXlOjA+lFCoebiAXazMahsHWL q48MlBbWbYNoy0koL5zzuqt8uXpk+kwyoX4jk/iETQkygOyypnnC0IG8v7fICPo2UxiX /yDw== MIME-Version: 1.0 X-Received: by 10.194.82.34 with SMTP id f2mr10258663wjy.25.1364077170950; Sat, 23 Mar 2013 15:19:30 -0700 (PDT) Received: by 10.216.112.7 with HTTP; Sat, 23 Mar 2013 15:19:30 -0700 (PDT) X-Originating-IP: [69.168.193.226] In-Reply-To: References: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> <073.92e203ac2ffbca6a9b6ecd285f8d0e00@trac.tools.ietf.org> Date: Sat, 23 Mar 2013 15:19:30 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmKc3PTWT+oBk+Efizq7K+t4crsmta6xdU6G8l9e/xYTQ6VBnqd6Mbl/Yjxgzr6MZfOcLBh Cc: "" , websec issue tracker , "" Subject: Re: [websec] #57: Re-add an upper limit to max-age 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, 23 Mar 2013 22:19:33 -0000 On Fri, Mar 22, 2013 at 7:13 PM, Yoav Nir wrote: > > On Mar 22, 2013, at 7:36 PM, Joseph Bonneau wrote: > >> On Fri, Mar 22, 2013 at 7:07 PM, Trevor Perrin wrote: >>> With a spec maximum (say 30 days), then you have a clear reference >>> point to plan around. >> >> Agreed. >> >> I have some stats I've been looking at from Google's web crawls about >> HSTS headers. Out of 12853 hosts I observed setting HSTS, 53% set of a >> max-age of 1 year. After that it's 15% 30 days, 12% 180 days, 10% 1 >> day, and a smattering of other choices (with a few large hosts like >> Twitter setting very long-lived max-age). > > As Ekr said in the meeting, there is a big difference here between HSTS a= nd HPKP. It doesn't matter if Paypal or some bank advertises HSTS for a mil= lion years. It's not likely that someone who has declared a policy for alwa= ys using secure transport will suddenly switch to non-secure transport. The= y might stop advertising HSTS, but they're not likely to stop insisting on = TLS use. Hi Yoav, Agreed that the issues around "pin lifetimes" are very different for HSTS and key pinning. If HSTS get mistakenly or maliciously set for your domain, it's no big deal. You just deploy SSL. If your domain gets pinned to keys you don't control, it's a big problem. > Something to consider is that if the max-age time is shorter than the tim= e between accesses to the site, the security of this mechanism is lost. I agree we'd like more security than a 30-day browser-side "key continuity" window. This is perhaps controversial, but I'd hope we could get that additional security *without* cranking up pin lifetimes, by considering ways to use pinning beyond just browser-side key continuity. For example: * Web crawlers could build pin lists for all sites they observe. * Browsers could periodically download a subset of these pin lists (for the most popular sites, or for communities of sites relevant to them). * "Trusted introducers" such as search engines could embed pins from a pin list into "secure links" that they serve. * Browsers could do online lookups to a pin list (whether blocking a la Convergence or after-the-fact a la Certificate Transparency). These ideas are all enabled or enhanced by key pinning, but they don't require long pin lifetimes. They just require pin lifetimes large enough that recrawling / redownloading pin lists / clearing caches etc. doesn't have to be done too frequently. > I understand Trevor's issue. Does it make a difference to a site operator= whether the site is partially bricked by bad pins for 30 days or 365 days? Consider cybersquatting or a domain name dispute, where someone loses control of a domain to its new (rightful) owner. The loser could set key pins before the domain is transferred, either for spite or to ransom the keys to the new owner. If the new owner has to wait 30 days before the domain is usable, that's a bummer but seems on the edge of tolerable. A year would be a long time. More generally, I think the important dictums here are: * First, do no harm * Second, don't scare users away! The biggest risk is not that the protection window will be too short, it's that we'll screw up the Internet, and the mechanism will be (or will be perceived as) too dangerous to use. So, I think it's best to push tradeoffs like this in the direction of safe, fail-open behavior, instead of trying to squeeze out every possible bit of "security". Trevor From palmer@google.com Wed Mar 27 15:43: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 34A5721F9047 for ; Wed, 27 Mar 2013 15:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 NRgDUx1UvqrQ for ; Wed, 27 Mar 2013 15:43:25 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id 2430421F87F5 for ; Wed, 27 Mar 2013 15:43:22 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id hv10so6875963vcb.26 for ; Wed, 27 Mar 2013 15:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=iw1HigbpAukTgAOvw/aW6QsEi0/nNFR0Aan1x81eHbY=; b=AoAkTiP9y9dOFxcqgJpg33nE9To7V/BfPXNh6evZgmQYk3slYfZ7A02ztW8skuMGyA EXUNYgN4rkS2rPuXMbn6+I+a5uKQjQ7t6mkm5q9qQsY6pPWew4Go9c9dhaQ78m0aBzby nk3T1the+Kuk8kDjqYEySG/7AtpCt2mTl0E6G3tLXK1Q7WsH9wiBr8XSEb0+a+oAQ8Vs 4T/IPGH+tu6EyGH89RXtFZqtNVAKBqwHG1ftTPggh6FrC4fLVFXEZSb4AtEBj7BKB/o2 dHboNRbGJGzHtYuLlansVeFRmpZKcX8nO0lkE8mgCfMS0mXdC5UlThsgsit3lEPkFB5b 9oxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=iw1HigbpAukTgAOvw/aW6QsEi0/nNFR0Aan1x81eHbY=; b=IM/HW9s6H3TCx3fvxOvvjHPQHGyhIJ+SOaR2YVxB0zBJUOH2K3pMDupsupa69XcDIt +U5apbKsO5naLSDlgn45WBOBFeotgT2VjbCxTsv+Bt0vv3lszWTMGVxmRX2ZBVsuy0jG ZvpIQ81n9WJCaVbs0iEh5bwBx+Ut22mCCdtDmIN88mB+wjqLblb+IhhkrIytSFQR4GRe 2SH0mx0Mcaa5HtamC/bT2r3/2Rnzk7tMOW3Xhm1w6PwyvAuqtA4dxb/1VOpGWa0hp/2b M6r79Ve5ETiWr5Yn39aNhMRtktDE6aPHzE4K0f3Zh6wF6vpSqPefpRCRwl3EEjGy5pmR ZEWQ== MIME-Version: 1.0 X-Received: by 10.220.76.129 with SMTP id c1mr4393916vck.48.1364424201510; Wed, 27 Mar 2013 15:43:21 -0700 (PDT) Received: by 10.58.179.19 with HTTP; Wed, 27 Mar 2013 15:43:21 -0700 (PDT) In-Reply-To: References: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> <073.92e203ac2ffbca6a9b6ecd285f8d0e00@trac.tools.ietf.org> Date: Wed, 27 Mar 2013 15:43:21 -0700 Message-ID: From: Chris Palmer To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnIG+BkQcDhLBDL9Yqxgd9zyJWrMIKRAFH77LzSf2I+LVK3ASo+MMUe7yMGcZ9nnzVLMs0MawL9WX0PS2sjHs3MLFXIETEKK03gfZeLjWCOTZWlvZu88DVQM02v/8oyRZuPdnY5jwveyWtZrl/xYR2iq19Mscz090OhOoETKGh1i6PdMZYuIFVKARfZ550YR6aGq+Bb Cc: "" , websec issue tracker , "" Subject: Re: [websec] #57: Re-add an upper limit to max-age 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, 27 Mar 2013 22:43:26 -0000 On Fri, Mar 22, 2013 at 7:13 PM, Yoav Nir wrote: > OTOH a particular public key might be replaced because of switching certi= ficate vendors, because auditors don't like that key length any more, or be= cause your certificate vendor has decided that ECC is the way to go. Pinnin= g something that has an expiry date for an unlimited time could be a proble= m. If you have a planned pin set transition (new issuer, new key type, et c.), you can (and should!) update your PKP header to include the new pins weeks in advance of the actual transition. The UA MUST store the new pins (assuming your PKP header meets the requirements of a Valid Pinning Header, of course), and when you later make the deployment change, UAs will know about your new keys and Pin Validation will pass. You might also choose to lower your max-age during a time of transition, too; you might choose to bump it back up when going back into a steady state. You should also set your max-age to be in harmony with your deployment plans, of course. Depending on your needs, your max-age might be short indeed. Especially at the beginning of your deployment of HPKP, it's probably wise to set a low max-age until you are more certain how it's going to work out for your site. > Something to consider is that if the max-age time is shorter than the tim= e between accesses to the site, the security of this mechanism is lost. If = either the draft or the UA sets an upper limit of 30 days, then HKPK won't = work for pub.ietf.org. This is a site that I only use from one week before = an IETF meeting to one week following it. In between there are a little ove= r three months where I don't use the site at all. So it would make sense fo= r the site operator to set a max-age of 4 months. That limit may be inappro= priate for web mail or social media, but even those might be accessed from = different UAs at different times. For example, I might use my home computer= for a social media site while I'm at home, but use a smart phone or a lapt= op for the same site when I'm away from home. Yes, I discuss this trade-off in Security Considerations (in the working copy of the draft). I tend to agree with Trevor Perrin when he says, """So, I think it's best to push tradeoffs like this in the direction of safe, fail-open behavior, instead of trying to squeeze out every possible bit of "security".""" So, 30 days, or 60 days, we can argue about. But 1 year might be too long a time =E2=80=94 if we decide to have a mandated max max-age, instead = of just providing UA implementation advice. Is there consensus that we should mandate a max max-age, or consensus that we should not? FWIW, currently Google Chrome sets a limit of 10 weeks for the pre-loaded pin list. If you haven't gotten a fresh update of Chrome (which contains the preloaded pins, baked in), then something is wrong and we fail open so that you can recover. Please consider that HPKP is not intended to be "perfect"; it has to work for the internet at large in a variety of site deployment and usage scenarios. It may very well be that it works better for sites that people visit every day or every week than for sites that you visit once per quarter. If Twitter can make use of it but pub.ietf.org cannot, that's still a net win even if not a perfect win. From trac+websec@trac.tools.ietf.org Wed Mar 27 15:55: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 DBFE021F8FFB for ; Wed, 27 Mar 2013 15:55:07 -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 XpFhJb4XYFIO for ; Wed, 27 Mar 2013 15:55:06 -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 9A11721F8570 for ; Wed, 27 Mar 2013 15:54:58 -0700 (PDT) Received: from localhost ([127.0.0.1]:40183 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UKzFB-0008IA-5B; Wed, 27 Mar 2013 23:54:57 +0100 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: palmer@google.com X-Trac-Project: websec Date: Wed, 27 Mar 2013 22:54:57 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/55#comment:2 Message-ID: <073.ec94ba2e71513562888c29f0af0b3306@trac.tools.ietf.org> References: <058.106749b7ec8d8775c9a7c03ff71b6de4@trac.tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <058.106749b7ec8d8775c9a7c03ff71b6de4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.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 Cc: websec@ietf.org Subject: Re: [websec] #55: Clarify that the newest pinning information takes precedence 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: Wed, 27 Mar 2013 22:55:09 -0000 #55: Clarify that the newest pinning information takes precedence Comment (by palmer@google.com): Ryan Sleevi has added text to the working copy that I believe resolves this ticket. Comments? https://code.google.com/p/key-pinning- draft/source/diff?spec=svn4f697cf66f747c18a5389922f484d9a1dbe85968&r=83bad3527ede8bb6ef52a8c220990ccd8762d9e7&format=side&path =/draft-ietf-websec-key-pinning.xml -- -------------------------------+-------------------------------- Reporter: palmer@google.com | Owner: palmer@google.com Type: defect | Status: assigned Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------- Ticket URL: websec From jbonneau@gmail.com Wed Mar 27 16:16: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 C4C0421F9007 for ; Wed, 27 Mar 2013 16:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 zsjoRgQE3r01 for ; Wed, 27 Mar 2013 16:16:45 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4E521F8FBE for ; Wed, 27 Mar 2013 16:16:45 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id bv4so1211596qab.8 for ; Wed, 27 Mar 2013 16:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=CWX/P4IhT0S5EIz62YiUACB9v1LXnY9DAf1Z2GYH40Y=; b=iLK1QXESDJzIR6kMJ65L7njmdrrh2HMnaZ7SFyGqvk68F7GfMojZN9iDKT5Gt0b/+g rfBne9sdv9bwRXVZ5HVxh6PAb+Z8df2/KhqvMkOk2PA+0hy7ZVmsyUWTqiek6QDukDWS 9h19V6CbxVgPR4IzGzwQpt8nRdLiuGoTSxKEAGOlWirHRQyFCPVnPiiNY0vkvvfsVS2E J3QAyqk78YbsEi3b5y48/x9UhDn1w0jYvXSXDV64NYs/ieoZVzDLpGVrqRwCF1PvWdKW aKg2RqK8Z0l2/UNONjmpcqso9C+L3UYx8faMj+AGAGWOF4jZMaO42vwx4RG8jchb+5aJ TXTw== X-Received: by 10.224.102.1 with SMTP id e1mr15100684qao.15.1364426204479; Wed, 27 Mar 2013 16:16:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.6.202 with HTTP; Wed, 27 Mar 2013 16:16:24 -0700 (PDT) In-Reply-To: References: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> <073.92e203ac2ffbca6a9b6ecd285f8d0e00@trac.tools.ietf.org> From: Joseph Bonneau Date: Wed, 27 Mar 2013 19:16:24 -0400 Message-ID: To: Chris Palmer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" , websec issue tracker , "" Subject: Re: [websec] #57: Re-add an upper limit to max-age 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, 27 Mar 2013 23:16:55 -0000 > So, 30 days, or 60 days, we can argue about. But 1 year might be too > long a time =E2=80=94 if we decide to have a mandated max max-age, instea= d of > just providing UA implementation advice. > > Is there consensus that we should mandate a max max-age, or consensus > that we should not? To me, the question isn't so much about how long sites will want to set max-age for, it's "How long would HPKP-browser makers allow a domain to be bricked before caving to pressure to add it to some whitelist/revocation list?" I think it's inevitable that some foo.com *will* brick themselves using HPKP (or possibly be bricked maliciously) and then come crawling to Chrome (or other implementing browsers) asking to be bailed out. If there were a max-age of 60 days, would the Chrome team take a hard line of "Sorry foo.com, you'll just have to wait it out"? Or would they ship a patch to disables HPKP for foo.com, fearing that otherwise some users will just switch to another browser to regain access? If the former is more likely, then a max max-age of 60 days is reasonable. If the latter is more likely, then I'd argue against having a max max-age at all and instead plan to deal with failures in a deus ex machina way. From tom@ritter.vg Wed Mar 27 19:54: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 AEE6821F9434 for ; Wed, 27 Mar 2013 19:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 LhZQKU9+ONIh for ; Wed, 27 Mar 2013 19:54:21 -0700 (PDT) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2DE21F9433 for ; Wed, 27 Mar 2013 19:54:21 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id x11so935513pdj.38 for ; Wed, 27 Mar 2013 19:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=6SCRvHGUBjecg+07qUelraA4exxuDAqic69qchmo/sM=; b=vSw9x19YNykJDjR04e9B7HtlF6zXksn8ZS8PgudoZNwgBs+PYhqRJTnezw11luRmT+ Bai29bi/l2+NjQMshw3X8j0h0oWcrUQVy85GdTjSIAiuCjJ8ky0e1cI1FpfYMEgWYdnU NkoT80g6D9PYhdPeuX5CZdnQBYukueQaegHoA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=6SCRvHGUBjecg+07qUelraA4exxuDAqic69qchmo/sM=; b=oGgLOZITadZYsJrkAhFUvAOa7E64d5J7Ds5rM6zo0rfBHfmsNh6DkF6dT514Y6OCjd A8MhluqxfICorb+GFvQniXHx+J9rb9wVOrTEHVFKrEJrF8ren6pS1nd8+Dc2mEzzpAxh D8TDD9JI5jt0WhfoyqxbUu+Bow2FN6jPEtS4YOEpRLc+pmd8b7w5po2ZdLacaIciQBia 4y0D87BLJI2IYZWZehrV8apliA+/wVrqB0PPE8lirYJMKmQR8x1i6mHxueyZ7kwldREu 6Htz4y13bc3hGAjdB8PE8XFy5lhw/p822Uml+yZu8hOnI0ySsyxPQ03mNnZ9pYj24bfJ oE5Q== X-Received: by 10.66.197.228 with SMTP id ix4mr33225539pac.91.1364439260915; Wed, 27 Mar 2013 19:54:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.189.72 with HTTP; Wed, 27 Mar 2013 19:54:00 -0700 (PDT) In-Reply-To: <073.ec94ba2e71513562888c29f0af0b3306@trac.tools.ietf.org> References: <058.106749b7ec8d8775c9a7c03ff71b6de4@trac.tools.ietf.org> <073.ec94ba2e71513562888c29f0af0b3306@trac.tools.ietf.org> From: Tom Ritter Date: Wed, 27 Mar 2013 22:54:00 -0400 Message-ID: To: websec issue tracker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm2TvE0oua7quw2Ul/hjY/P2JQh5VZVJ6jHPvlsiZmi5X4G7A6o1le9Ztyw2Bnt9WpiDAtr Cc: websec@ietf.org Subject: Re: [websec] #55: Clarify that the newest pinning information takes precedence 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, 28 Mar 2013 02:54:21 -0000 " The UA MUST evict all expired Known Pinned Hosts if at any time, an expired Known Pinned Host exists in the cache" I use rrdtool to keep 5 years of statistics for my server. Once, I accidentally set the date forward, to 2038, wiping out my statistics - there was no way to recover, because rrdtool dutifully wiped all this expired data. Using the word 'evict' seems particularly dangerous, for both active ntp attacks, and accidental wiping. -tom From ynir@checkpoint.com Thu Mar 28 18:33: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 E12DF21F84B0 for ; Thu, 28 Mar 2013 18:33:27 -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 F8DNt2ycIOOK for ; Thu, 28 Mar 2013 18:33:27 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9B90821F84A9 for ; Thu, 28 Mar 2013 18:33: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 r2T1X2sY018384; Fri, 29 Mar 2013 04:33:02 +0300 X-CheckPoint: {5154ED9D-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Fri, 29 Mar 2013 04:33:01 +0300 From: Yoav Nir To: Joseph Bonneau Thread-Topic: [websec] #57: Re-add an upper limit to max-age Thread-Index: AQHOJ0X4m4jM1OHiCUi5AgAOGVjbxZiyNAIAgAAIBoCAACvZgIAHoQKAgAAJPACAAbiWgA== Date: Fri, 29 Mar 2013 01:33:01 +0000 Message-ID: <5B9868F5-6DF8-4D9E-BCE4-248063103A65@checkpoint.com> References: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> <073.92e203ac2ffbca6a9b6ecd285f8d0e00@trac.tools.ietf.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.137] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , websec issue tracker , "" Subject: Re: [websec] #57: Re-add an upper limit to max-age 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, 29 Mar 2013 01:33:28 -0000 On Mar 27, 2013, at 7:16 PM, Joseph Bonneau wrote: >> So, 30 days, or 60 days, we can argue about. But 1 year might be too >> long a time =97 if we decide to have a mandated max max-age, instead of >> just providing UA implementation advice. >>=20 >> Is there consensus that we should mandate a max max-age, or consensus >> that we should not? >=20 > To me, the question isn't so much about how long sites will want to > set max-age for, it's "How long would HPKP-browser makers allow a > domain to be bricked before caving to pressure to add it to some > whitelist/revocation list?" I think it's inevitable that some foo.com > *will* brick themselves using HPKP (or possibly be bricked > maliciously) and then come crawling to Chrome (or other implementing > browsers) asking to be bailed out. Hopefully, it's not just Google that implements this. I guess any browser t= hat implements this will have some kind of reset button (like they have for= other stuff) that will erase all pins. So the site is not really bricked, = but still it's pretty embarrassing to have to have a message on their home = page like "Chrome for Mac OS X users of foo.com, due to an administrative e= rror, please select the 'Clear Browsing Data=85' menu item from the Chrome = menu, select 'the beginning of time' from the dropdown menu, and check the = 'dynamic public key pins' box. Then click 'Clear browsing data'. Sorry for = the inconvenience." > If there were a max-age of 60 days, would the Chrome team take a hard > line of "Sorry foo.com, you'll just have to wait it out"? Or would > they ship a patch to disables HPKP for foo.com, fearing that otherwise > some users will just switch to another browser to regain access? I don't think any of us like the answer, but this probably depends on who '= foo' is. You don't brick Gmail, Hotmail, Paypal, or any major bank in the U= S. http://www.brambleberry.com ? I don't see any of the major browser issu= ing a patch to bail them out. > If the former is more likely, then a max max-age of 60 days is > reasonable. If the latter is more likely, then I'd argue against > having a max max-age at all and instead plan to deal with failures in > a deus ex machina way. From ynir@checkpoint.com Thu Mar 28 18:35: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 6087921F84F8 for ; Thu, 28 Mar 2013 18:35:17 -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 r8qmBS6LQef3 for ; Thu, 28 Mar 2013 18:35:16 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC2B21F84F6 for ; Thu, 28 Mar 2013 18:35:16 -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 r2T1ZDgr018594; Fri, 29 Mar 2013 04:35:13 +0300 X-CheckPoint: {5154EE21-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Fri, 29 Mar 2013 04:35:13 +0300 From: Yoav Nir To: IETF WebSec WG Thread-Topic: [websec] #55: Clarify that the newest pinning information takes precedence Thread-Index: Ac2uQVh1gfgp5oAbRvq4qJa/hOeYpx86/5WAADfmVQA= Date: Fri, 29 Mar 2013 01:35:13 +0000 Message-ID: References: <058.106749b7ec8d8775c9a7c03ff71b6de4@trac.tools.ietf.org> <073.ec94ba2e71513562888c29f0af0b3306@trac.tools.ietf.org> In-Reply-To: <073.ec94ba2e71513562888c29f0af0b3306@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.137] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <7A9F8FA7FADE2944956B2B834EA30729@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] #55: Clarify that the newest pinning information takes precedence 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, 29 Mar 2013 01:35:17 -0000 The text works for me. On Mar 27, 2013, at 6:54 PM, websec issue tracker wrote: > #55: Clarify that the newest pinning information takes precedence >=20 >=20 > Comment (by palmer@google.com): >=20 > Ryan Sleevi has added text to the working copy that I believe resolves > this ticket. Comments? >=20 > https://code.google.com/p/key-pinning- > draft/source/diff?spec=3Dsvn4f697cf66f747c18a5389922f484d9a1dbe85968&r=3D= 83bad3527ede8bb6ef52a8c220990ccd8762d9e7&format=3Dside&path > =3D/draft-ietf-websec-key-pinning.xml >=20 > --=20 > -------------------------------+-------------------------------- > Reporter: palmer@google.com | Owner: palmer@google.com > Type: defect | Status: assigned > Priority: major | Milestone: > Component: key-pinning | Version: > Severity: - | Resolution: > Keywords: | > -------------------------------+-------------------------------- >=20 > Ticket URL: > websec >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From jbonneau@gmail.com Fri Mar 29 10:45: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 4BDD521F9159 for ; Fri, 29 Mar 2013 10:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 FMaa767fy3w2 for ; Fri, 29 Mar 2013 10:45:58 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6220B21F86D9 for ; Fri, 29 Mar 2013 10:45:58 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id o13so45317qaj.3 for ; Fri, 29 Mar 2013 10:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=wpDte95WiResj7OpPCtcUTAwaBqrl+S0q4gNcvzewEQ=; b=nuHsp2M0WcIOMAtI0+W3fESrxnZlqnDABtdN6lXvvk99S+d2JmJp5lODXIOAQjjE5k aleWpmTkZ0nVm9zeVTrAjS3Fa781znezvTPvqs1exoJpsl+awJBCnjycGejZWlzJADqt dJ6RyQmrA9OzUqA4RzWbroGbO18bu+QQcweMg5++zBoXO/EshevUCNXP7PFFG3/d2QBq hRPSjj6yjqaP1YiCQDB7xC5H9d7cf4nTw0b5Rb+T63PyA6kus6PKT4h/GsUWVrsZ4SlA TTRaEPCkZajVO3mWX5NkrJcwsAD6nSIDdfR+5u950ikB09/tNSp3pJCYGz9XoYJT9DOy QrVg== X-Received: by 10.229.205.194 with SMTP id fr2mr1483839qcb.42.1364579157909; Fri, 29 Mar 2013 10:45:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.6.202 with HTTP; Fri, 29 Mar 2013 10:45:36 -0700 (PDT) In-Reply-To: <5B9868F5-6DF8-4D9E-BCE4-248063103A65@checkpoint.com> References: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> <073.92e203ac2ffbca6a9b6ecd285f8d0e00@trac.tools.ietf.org> <5B9868F5-6DF8-4D9E-BCE4-248063103A65@checkpoint.com> From: Joseph Bonneau Date: Fri, 29 Mar 2013 13:45:36 -0400 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" , websec issue tracker , "" Subject: Re: [websec] #57: Re-add an upper limit to max-age 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, 29 Mar 2013 17:45:59 -0000 > Hopefully, it's not just Google that implements this. I guess any browser= that implements this will have some kind of reset button (like they have f= or other stuff) that will erase all pins. So the site is not really bricked= , but still it's pretty embarrassing to have to have a message on their hom= e page like "Chrome for Mac OS X users of foo.com, due to an administrative= error, please select the 'Clear Browsing Data=E2=80=A6' menu item from the= Chrome menu, select 'the beginning of time' from the dropdown menu, and ch= eck the 'dynamic public key pins' box. Then click 'Clear browsing data'. So= rry for the inconvenience." Perhaps we have a different working definition of "bricked"? By bricked, I meant that HPKP pins were set which the site no longer has the ability to satisfy, period. There are many ways that this could happen-pinning to two end-entity keys and losing the private keys, attempting to pin to a CA key but entering the hash incorrectly, and still having the pins accepted since the end-entity key pin is valid, or a malicious bricking with a mis-issued certificate. In this case, a bricked domain would be unable to show anything at all to users, so they couldn't ask users to hit a "reset pins" button as you suggest. Some users might figure it out through an alternate channel like Googling "why is foo.com down??", but it would be awful to train users to ever follow advice to nuke their local state like that. >> If there were a max-age of 60 days, would the Chrome team take a hard >> line of "Sorry foo.com, you'll just have to wait it out"? Or would >> they ship a patch to disables HPKP for foo.com, fearing that otherwise >> some users will just switch to another browser to regain access? > > I don't think any of us like the answer, but this probably depends on who= 'foo' is. You don't brick Gmail, Hotmail, Paypal, or any major bank in the= US. http://www.brambleberry.com ? I don't see any of the major browser is= suing a patch to bail them out. I'm can live with that answer, though I'd be curious to hear from the Chrome developers (who are likely to be the pioneers here). If a channel to whitelist misconfigured HPKP domains is going to be built, it changes the discussion around max-age limits to be mostly a performance optimization and I don't think it's a good security tradeoff. From ynir@checkpoint.com Fri Mar 29 14:16: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 A191721E8050 for ; Fri, 29 Mar 2013 14:16:06 -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 mmVk1pDMBQlA for ; Fri, 29 Mar 2013 14:16:02 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 02E8921E804D for ; Fri, 29 Mar 2013 14:15:58 -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 r2TLFj1E018827; Sat, 30 Mar 2013 00:15:45 +0300 X-CheckPoint: {515602C4-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Sat, 30 Mar 2013 00:15:45 +0300 From: Yoav Nir To: Joseph Bonneau Thread-Topic: [websec] #57: Re-add an upper limit to max-age Thread-Index: AQHOJ0X4m4jM1OHiCUi5AgAOGVjbxZiyNAIAgAAIBoCAACvZgIAHoQKAgAAJPACAAbiWgIAA/uQAgAA60gA= Date: Fri, 29 Mar 2013 21:15:44 +0000 Message-ID: <91E15149-9991-4B98-B182-53B7CA0D3285@checkpoint.com> References: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> <073.92e203ac2ffbca6a9b6ecd285f8d0e00@trac.tools.ietf.org> <5B9868F5-6DF8-4D9E-BCE4-248063103A65@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.235] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , websec issue tracker , "" Subject: Re: [websec] #57: Re-add an upper limit to max-age 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, 29 Mar 2013 21:16:06 -0000 On Mar 29, 2013, at 1:45 PM, Joseph Bonneau wrote: >> Hopefully, it's not just Google that implements this. I guess any browse= r that implements this will have some kind of reset button (like they have = for other stuff) that will erase all pins. So the site is not really bricke= d, but still it's pretty embarrassing to have to have a message on their ho= me page like "Chrome for Mac OS X users of foo.com, due to an administrativ= e error, please select the 'Clear Browsing Data=85' menu item from the Chro= me menu, select 'the beginning of time' from the dropdown menu, and check t= he 'dynamic public key pins' box. Then click 'Clear browsing data'. Sorry f= or the inconvenience." >=20 > Perhaps we have a different working definition of "bricked"? By > bricked, I meant that HPKP pins were set which the site no longer has > the ability to satisfy, period. There are many ways that this could > happen-pinning to two end-entity keys and losing the private keys, > attempting to pin to a CA key but entering the hash incorrectly, and > still having the pins accepted since the end-entity key pin is valid, > or a malicious bricking with a mis-issued certificate. In this case, a > bricked domain would be unable to show anything at all to users, so > they couldn't ask users to hit a "reset pins" button as you suggest. This assumes all these domains are also STS (H or not). If the site also ha= s an HTTP server (like most are now), then that server can display the mess= age. Perhaps there should be some website that lists bricked domains, perhaps ma= intained by the browser vendors or a consortium (CABF?). So when you get th= e HPKP error screen, you will not be able to click through, but you will be= able to get the list of recently bricked domains. So if the site you were = looking for is listed there, you would shake your head at their incompetenc= e, and proceed to clear pins (or clear the specific pin if you're more secu= rity conscious). Of course, that site has to be strictly secure. From ynir@checkpoint.com Fri Mar 29 19:05: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 38C3821E804A for ; Fri, 29 Mar 2013 19:05:43 -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 yjMeNedyBf0U for ; Fri, 29 Mar 2013 19:05:42 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id DDF2E1F0CF7 for ; Fri, 29 Mar 2013 19:05:41 -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 r2U25IFb021700; Sat, 30 Mar 2013 05:05:18 +0300 X-CheckPoint: {5156469F-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Sat, 30 Mar 2013 05:05:18 +0300 From: Yoav Nir To: Ryan Sleevi Thread-Topic: [websec] #57: Re-add an upper limit to max-age Thread-Index: AQHOJ0X4m4jM1OHiCUi5AgAOGVjbxZiyNAIAgAAIBoCAACvZgIAHoQKAgAAJPACAAbiWgIAA/uQAgAA6nYCAAFEdAA== Date: Sat, 30 Mar 2013 02:05:18 +0000 Message-ID: <77D0BAFD-9345-4F92-A8A3-641DADA771AA@checkpoint.com> References: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> <073.92e203ac2ffbca6a9b6ecd285f8d0e00@trac.tools.ietf.org> <5B9868F5-6DF8-4D9E-BCE4-248063103A65@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.138] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-ID: <4DC0FA451EA9CA40ACA2EC399F30564A@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , websec issue tracker Subject: Re: [websec] #57: Re-add an upper limit to max-age 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, 30 Mar 2013 02:05:43 -0000 On Mar 29, 2013, at 5:15 PM, Ryan Sleevi wrote: > On Fri, Mar 29, 2013 at 10:45 AM, Joseph Bonneau wro= te: >>> Hopefully, it's not just Google that implements this. I guess any brows= er that implements this will have some kind of reset button (like they have= for other stuff) that will erase all pins. So the site is not really brick= ed, but still it's pretty embarrassing to have to have a message on their h= ome page like "Chrome for Mac OS X users of foo.com, due to an administrati= ve error, please select the 'Clear Browsing Data=85' menu item from the Chr= ome menu, select 'the beginning of time' from the dropdown menu, and check = the 'dynamic public key pins' box. Then click 'Clear browsing data'. Sorry = for the inconvenience." >>=20 >> Perhaps we have a different working definition of "bricked"? By >> bricked, I meant that HPKP pins were set which the site no longer has >> the ability to satisfy, period. There are many ways that this could >> happen-pinning to two end-entity keys and losing the private keys, >> attempting to pin to a CA key but entering the hash incorrectly, and >> still having the pins accepted since the end-entity key pin is valid, >> or a malicious bricking with a mis-issued certificate. In this case, a >> bricked domain would be unable to show anything at all to users, so >> they couldn't ask users to hit a "reset pins" button as you suggest. >> Some users might figure it out through an alternate channel like >> Googling "why is foo.com down??", but it would be awful to train users >> to ever follow advice to nuke their local state like that. >=20 > So, certainly, as discussed during past meetings, and similar to the > discussions of HSTS, HPKP represents potential privacy bits being > disclosed to an attacker ("Have you been here before, and if so, > when/under what keys?"). As such, it's natural to assume/expect that > browsers will have a way to clear received dynamic pins, as part of > the normal clearing of privacy state-related data. >=20 > However, sites / site operators encouraging users to do so would be > bad for users' security - it would essentially flush their pins, > allowing potentially misissued certs to be used. If I was a 'clever' > attacker, and I had the ability to display such messages, then in the > face of being unable to attack a pinned site, I would look for a > popular-but-not-pinned site and deliberately inject bad pins (DoS'ing > the site from the users' perspective), along with some sort of message > of "Hey, clear your pins for this site to work" >=20 > Once the user cleared their pins, I would be able to attack the target > site, which would now be unpinned. >=20 > Alternative models (such as temporarily ignoring pins) sort of flies > in the face of our experiences with HSTS and the general > browser/usability issues with bypassing warnings. Clearing on a > per-site basis is the same as a bypass mode, and then we're just > talking about the number of clicks to get there - also a poor security > experience. All true, but if I want to delete my pins, I will, even if I have to search= the Internet (using Google, of course) for how to edit the pins on Chrome.= I only hope that instructing your users to do this will be enough of a "do= ghouse" for site operators. As it is, expired certs and chains that don't c= hain are becoming more and more rare. The power of embarrassment seems to b= e working there, even though there is a click-through option. Getting back to the subject of the thread, I still don't see the difference= for a site operator between being bricked for 60 days and being bricked fo= r a year. For an only retailer it's catastrophe either way. Yoav From sleevi@google.com Fri Mar 29 14:15: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 4805A21E804D for ; Fri, 29 Mar 2013 14:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[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 ZUgNaHn9in6x for ; Fri, 29 Mar 2013 14:15:31 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2B55821E804E for ; Fri, 29 Mar 2013 14:15:24 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id x14so931007ief.21 for ; Fri, 29 Mar 2013 14:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=d1PBt4TCgMUHpGPAgVF3qhNY5OmS1uD9n2jgD+w8Zg0=; b=I/CWcNNqTkoA/57NvWZZCipdgkjUkHbW3oXMr9WMcGpUh4XKs0BwFdG849e/qha7JY tIBrlNSLb+G4xFTQ1H95IHbdDS8mu7RtygABqzGumMMU7dtBAUGzJ/80NPRr4zqEX3SB 5aSQjisQ9RAZrYtMOfpO1OzONalizclpwu5G5D2ITlzU+LEX20CqbQ+iDYxC3piGRf3/ gQOR6+x4TFCGIcVlDAacv0TKiFd3qznT8SI+AbjPlMfzogPPLNNUSobPKCTS2H5lgYae UGcSmkIGdVz5M2/ugT8yz5FMJlEelwNxYJOuwUpo/FekKlnJfGvliX39i3fSEwlUPSuA MasA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=d1PBt4TCgMUHpGPAgVF3qhNY5OmS1uD9n2jgD+w8Zg0=; b=N2Vh4xPxJBFy5IkiLTNe5Ji8SvWdZtJhET5/c1fzTXRorBgxDXqLzVfh5Y/jGfOKCV Pl+akmFu4QCi0j3y/eXqeNoiF0/WYuW6iDgULCsKFwVD+NP2fu+dVb0Os9qL3xNKRRvK j2ItvSzklXSD3HSIBYTeB8TMPfccnWgpIsRnmFyVMT/+TFyEQLfvE1o+0ZTYfLY92WrQ vxDZbafVfiF2pvnx7ZjYQ3mIYbrLGQPE2+ssxZPQCyI0wY4hUmgB4xkjyD5WmriVsMO+ bD/aMZJoWFRGIh1H2fvf3I1Q/lmYymHyvlLSAfHcEu+xodjv6Oe37BKEyW8hp1sh6KsD +4hA== MIME-Version: 1.0 X-Received: by 10.50.13.208 with SMTP id j16mr84558igc.73.1364591723793; Fri, 29 Mar 2013 14:15:23 -0700 (PDT) Received: by 10.64.35.113 with HTTP; Fri, 29 Mar 2013 14:15:23 -0700 (PDT) In-Reply-To: References: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> <073.92e203ac2ffbca6a9b6ecd285f8d0e00@trac.tools.ietf.org> <5B9868F5-6DF8-4D9E-BCE4-248063103A65@checkpoint.com> Date: Fri, 29 Mar 2013 14:15:23 -0700 Message-ID: From: Ryan Sleevi To: Joseph Bonneau Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl8SifmoVKXWkP7LQAha8TBFSLGz0TeP6Yx1eP/8iDTRlhwkLMS6CmQjSajSclaryhS/KQwhdkH/opoOdaK78j4iDUr0xoPDSJQyQrVrwxm3DKd0pbtAfE7nAdATuoWxNvs9rkr+YZXmh53TzlciKjnZW6LnqZKqE0oUf7qDAXazCvBNDsVHQAeeZTtJ9dfWnpYhU+x X-Mailman-Approved-At: Fri, 29 Mar 2013 19:39:39 -0700 Cc: "" , websec issue tracker Subject: Re: [websec] #57: Re-add an upper limit to max-age 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, 29 Mar 2013 21:15:36 -0000 On Fri, Mar 29, 2013 at 10:45 AM, Joseph Bonneau wrote= : >> Hopefully, it's not just Google that implements this. I guess any browse= r that implements this will have some kind of reset button (like they have = for other stuff) that will erase all pins. So the site is not really bricke= d, but still it's pretty embarrassing to have to have a message on their ho= me page like "Chrome for Mac OS X users of foo.com, due to an administrativ= e error, please select the 'Clear Browsing Data=85' menu item from the Chro= me menu, select 'the beginning of time' from the dropdown menu, and check t= he 'dynamic public key pins' box. Then click 'Clear browsing data'. Sorry f= or the inconvenience." > > Perhaps we have a different working definition of "bricked"? By > bricked, I meant that HPKP pins were set which the site no longer has > the ability to satisfy, period. There are many ways that this could > happen-pinning to two end-entity keys and losing the private keys, > attempting to pin to a CA key but entering the hash incorrectly, and > still having the pins accepted since the end-entity key pin is valid, > or a malicious bricking with a mis-issued certificate. In this case, a > bricked domain would be unable to show anything at all to users, so > they couldn't ask users to hit a "reset pins" button as you suggest. > Some users might figure it out through an alternate channel like > Googling "why is foo.com down??", but it would be awful to train users > to ever follow advice to nuke their local state like that. So, certainly, as discussed during past meetings, and similar to the discussions of HSTS, HPKP represents potential privacy bits being disclosed to an attacker ("Have you been here before, and if so, when/under what keys?"). As such, it's natural to assume/expect that browsers will have a way to clear received dynamic pins, as part of the normal clearing of privacy state-related data. However, sites / site operators encouraging users to do so would be bad for users' security - it would essentially flush their pins, allowing potentially misissued certs to be used. If I was a 'clever' attacker, and I had the ability to display such messages, then in the face of being unable to attack a pinned site, I would look for a popular-but-not-pinned site and deliberately inject bad pins (DoS'ing the site from the users' perspective), along with some sort of message of "Hey, clear your pins for this site to work" Once the user cleared their pins, I would be able to attack the target site, which would now be unpinned. Alternative models (such as temporarily ignoring pins) sort of flies in the face of our experiences with HSTS and the general browser/usability issues with bypassing warnings. Clearing on a per-site basis is the same as a bypass mode, and then we're just talking about the number of clicks to get there - also a poor security experience. > >>> If there were a max-age of 60 days, would the Chrome team take a hard >>> line of "Sorry foo.com, you'll just have to wait it out"? Or would >>> they ship a patch to disables HPKP for foo.com, fearing that otherwise >>> some users will just switch to another browser to regain access? >> >> I don't think any of us like the answer, but this probably depends on wh= o 'foo' is. You don't brick Gmail, Hotmail, Paypal, or any major bank in th= e US. http://www.brambleberry.com ? I don't see any of the major browser i= ssuing a patch to bail them out. > > I'm can live with that answer, though I'd be curious to hear from the > Chrome developers (who are likely to be the pioneers here). If a > channel to whitelist misconfigured HPKP domains is going to be built, > it changes the discussion around max-age limits to be mostly a > performance optimization and I don't think it's a good security > tradeoff. I don't have any answer for this at this time. There are obviously a set of security trade-offs here. Do you trust/want your browser vendor to deliver secure pins (aka pre-loaded pins)? Do you trust/want your browser vendor to deliver unpins (of dynamic pins)? The risks and likely responses to the first question are very different than those of the second.