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?