[websec] Issue 55 - Key pinning should clarify that the newest pinning information takes precedence

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

Return-Path: <ryan-ietfhasmat@sleevi.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7213921F88E2 for <websec@ietfa.amsl.com>; 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-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id QddmINvZMG3r for <websec@ietfa.amsl.com>; Mon, 4 Mar 2013 16:58:05 -0800 (PST)
Received: from homiemail-a65.g.dreamhost.com (caiajhbdcaid.dreamhost.com []) by ietfa.amsl.com (Postfix) with ESMTP id C019221F88A0 for <websec@ietf.org>; Mon, 4 Mar 2013 16:57:57 -0800 (PST)
Received: from homiemail-a65.g.dreamhost.com (localhost []) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id E91957E405D for <websec@ietf.org>; 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 []) (Authenticated sender: ryan@sleevi.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPA id E64EF7E4058 for <websec@ietf.org>; Mon, 4 Mar 2013 16:57:56 -0800 (PST)
Received: from (proxying for (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Mon, 4 Mar 2013 16:57:56 -0800
Message-ID: <b6009964af0dae16c45619eb94c0f0e9.squirrel@webmail.dreamhost.com>
Date: Mon, 4 Mar 2013 16:57:56 -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 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 <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: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

In draft-04, Section 2.7
addresses this by indicating that UAs MUST use the newest information

Note: This does not normatively describe how a UA must determine newest.
The assumption here is that this represents the "newest observed", but the
question is whether or not that should be explicitly specified.

For example, imagine a UA that supports automatic updates to Preloaded Pin
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=0. Later, at T=5, it observes a Max-Age of 0,
effectively unpinning the host. At T=10, the UA vendor ships a new update
to the preloaded pin list that adds Site 2, but which has not been updated
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. 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?