Re: [websec] HPKP and preloaded pin lists

[Yoav Nir <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> 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