Subject: [websec] HPKP and preloaded pin lists

From: Trevor Perrin <[email-masked]>
Date: Thu, 20 Jun 2013 14:09:40 -0700

Hi,

I'm not sure I understand section 2.7 on "Interactions With Preloaded Pin
Lists".

At first glance it seems clear:  Both preloaded and dynamic pins MUST store
the "Effective Pin Date" when the pin was most recently observed, and
browsers MUST use only the most recent information.  E.g.:

T10 - Crawler notes a pin for "example.com"
T15 - Browser notes a different pin for "example.com"
T20 - Crawler sends preloaded pin to Browser

In this case, the browser MUST ignore the preloaded pin, and only apply the
pin it noted at T15.

But what if the browser-noted pin has a max-age of 0 or 1?  Or what if the
T15 connection occurs over a secure transport but has no PKP header?  The
spec says:

"If the result of noting a Valid Pinning Header is to disable pinning for
the host, such as through supplying a max-age directive with a value of 0,
UAs MUST allow this new information to override any other pinning data.
 That is, a host must be able to un-pin itself, even in the presence of
built-in pins."

That seems to imply the browser needs to remember "un-pinning" responses it
receives (i.e. max-age=0 or no PKP header), and expired pins, on the chance
that any of these might "un-pin" a preloaded pin it receives later?

That seems fairly complicated, and rather inflexible (I could imagine a
browser might trust its preload data more than dynamic data, and prefer
that take precedence).

So what if browsers were simply allowed to apply *either* the preload or
dynamic pin, or both?

The browser could choose to apply a complex, time-based algorithm like
above, or do something simpler like apply both pins, or let preloads take
precedence.

This also allows for implementations which don't need to store either the
"Effective Pin Date" (only the expiration time), or "un-pinning" entries.

Thoughts?

Trevor

---

From: Joseph Bonneau <[email-masked]>
Date: Sat, 22 Jun 2013 11:45:20 -0400

> In this case, the browser MUST ignore the preloaded pin, and only apply
> the pin it noted at T15.
>

I would support changing this from MUST to SHOULD, with the understanding
that browsers may have forgotten the pin noted at T15 in Trevor's example
for multiple possible reasons (space constraints, user clears history,
etc.) in which case they will revert to the preloaded pin. In practice a
site attempting to un-pin a bad preloaded pin will have to serve the
"un-pin" header for the lifetime of the bad preloaded pin no matter what,
because some browsers may never visit the site site until the end of the
life of the bad preload. So I don't see that making this a MUST makes life
any easier for site operators, and as Trevor pointed out it may cause
excessive complexity for browsers.

Joe

---

From: Yoav Nir <[email-masked]>
Date: Sun, 23 Jun 2013 06:19:06 +0000

I think remembering the nullified and expired pins for max-max-age adds complexity. It's fine to do, but we shouldn't require it.

A website that issues a bad pin for 30 days has to live with the consequences of that pin for all of those 30 days. Getting a pre-loaded pin list could save you and unpin a particular client, but that can turn on you and bite you and pin a client that had not been pinned before. I think that on balance it is still better to get the pins from a crawler. Maybe the crawlers should have some web interface that allows someone (the website administrator in this case) to request that a particular server be scanned (much like SSL-pulse has)

So knowing that there is a chance for both good and bad interactions with pre-loaded pins, and that the damage is anyway limited by max-max-age, I think we should leave it to implementations rather than add mandates.

Yoav (with no hats)

On Jun 21, 2013, at 12:09 AM, Trevor Perrin <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

I'm not sure I understand section 2.7 on "Interactions With Preloaded Pin Lists".

At first glance it seems clear:  Both preloaded and dynamic pins MUST store the "Effective Pin Date" when the pin was most recently observed, and browsers MUST use only the most recent information.  E.g.:

T10 - Crawler notes a pin for "example.com<http://example.com/>"
T15 - Browser notes a different pin for "example.com<http://example.com/>"
T20 - Crawler sends preloaded pin to Browser

In this case, the browser MUST ignore the preloaded pin, and only apply the pin it noted at T15.

But what if the browser-noted pin has a max-age of 0 or 1?  Or what if the T15 connection occurs over a secure transport but has no PKP header?  The spec says:

"If the result of noting a Valid Pinning Header is to disable pinning for the host, such as through supplying a max-age directive with a value of 0, UAs MUST allow this new information to override any other pinning data.  That is, a host must be able to un-pin itself, even in the presence of built-in pins."

That seems to imply the browser needs to remember "un-pinning" responses it receives (i.e. max-age=0 or no PKP header), and expired pins, on the chance that any of these might "un-pin" a preloaded pin it receives later?

That seems fairly complicated, and rather inflexible (I could imagine a browser might trust its preload data more than dynamic data, and prefer that take precedence).

So what if browsers were simply allowed to apply *either* the preload or dynamic pin, or both?

The browser could choose to apply a complex, time-based algorithm like above, or do something simpler like apply both pins, or let preloads take precedence.

This also allows for implementations which don't need to store either the "Effective Pin Date" (only the expiration time), or "un-pinning" entries.

Thoughts?

Trevor