[websec] Issue 53 - Key pinning should clarify status of pin validation with private trust anchors

"Ryan Sleevi" <ryan-ietfhasmat@sleevi.com> Tue, 05 March 2013 00:57 UTC

Return-Path: <ryan-ietfhasmat@sleevi.com>
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 <websec@ietfa.amsl.com>; 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 <websec@ietfa.amsl.com>; 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 <websec@ietf.org>; 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 <websec@ietf.org>; 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 <websec@ietf.org>; 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, 04 Mar 2013 16:57:20 -0800
From: Ryan Sleevi <ryan-ietfhasmat@sleevi.com>
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 <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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 implemented
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, having
the UA disable enforcement selectively is strictly less worse, from a
security perspective, than having the UA disable enforcement entirely, and
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 proposed
text sufficiently addresses the issue as originally raised?