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

From: "Ryan Sleevi" <[email-masked]>
Date: Mon, 4 Mar 2013 16:57:56 -0800

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 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?

---

From: Tom Ritter <[email-masked]>
Date: Tue, 5 Mar 2013 21:55:42 -0500

> 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: "Ryan Sleevi" <[email-masked]>
Date: Wed, 6 Mar 2013 11:34:17 -0800

>  on expressing a standard behavior instead.

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.

---

From: Tom Ritter <[email-masked]>
Date: Wed, 6 Mar 2013 21:49:42 -0500

> 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