Re: [websec] #58: Should we pin only SPKI, or also names

[Trevor Perrin <[e-mail]>]

On Thu, Aug 15, 2013 at 12:18 PM, Ryan Sleevi
<[e-mail]> wrote:
>
> I think you're presuming a model where the site operator must work to
> independently discover every path possible, I don't think that's the goal
> at all. This is something that the CA can inform their customers of the
> pinning information.

Sure, we'd definitely like CAs to inform customers of root pinning changes.

My point was narrower:  These changes may occur either synchronously
or asynchronously with new cert issuance.  I.e. you may go to renew a
cert, and be informed that using it will require a pinning change.
But you might also get a cert with a 2-year validity period, and a
year into it the CA informs you that a pinning change will be required
in a few months.


> I think the argument that "browsers will be more effective at this"
> entirely disregards one of the (many) motivations for pinning - namely,
> that site operators *don't want* to trust the browsers for their security
> policy.

I'd distinguish between policy decision and enforcement.

Certainly we want to let sites decide their policy.  But I'd argue
that once a site has decided on, say, a "symantec, comodo, godaddy"
pinning policy, mapping this to a set of keys is a matter of
enforcement which it would be reasonable to trust browsers with.

I'd also argue that the more HPKP enables sites to focus on simply
declaring a CA policy instead of grappling with implementation details
such as multi-step update processes, the more useable and successful
this will be.


> I'm also not convinced that it's a reasonable assumption to assume that
> all other factors of the industry will remain constant with or without
> pinning. What I mean is that it's entirely reasonable to see CAs spin up
> special "pinning" roots, which the CA contractually agrees will experience
> much less churn/turnover than their 'traditional' roots.

That would be great.


> There is an extreme benefit to SPKI in that it's entirely unambiguous and
> is stable throughout the lifetime of a cert, whereas a CA naming scheme
> has been shown to be both ambiguous and unstable.

An SPKI pin is not necessarily stable through the lifetime of a cert.
Because pinning to SPKIs is rigidly fixed to a set of keys, it's more
likely to need changes, and thus - from the website's perspective -
less stable than a more "ambiguous" and flexible named pin.

The more compelling argument, for me, is that named pins have been
shown to be a lot more work, and we're not really sure how / where to
coordinate it.


> That's not to say I think they're unsolvable problems, but I equally don't
> think it's necessary to solve them now, as I believe pinning via SPKI
> still offers a viable path forward, with multiple possible solutions to
> some of the problems you've raised here.

I think it's reasonable to move forward in that way - best not enemy
of the good, etc., and there's plenty of new things to deploy here and
get comfortable with before adding more.


Trevor