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

From: "Ryan Sleevi" <[email-masked]>
Date: Thu, 15 Aug 2013 12:18:37 -0700

On Thu, August 15, 2013 1:20 am, Trevor Perrin wrote:
>  On Wed, Aug 14, 2013 at 4:44 PM, Gervase Markham <[email-masked]> wrote:
> > On 14/08/13 18:20, Trevor Perrin wrote:
> >> My point is that changes like CAs issuing new intermediates or
> >> deprecating old roots MUST get incorporated into website pins somehow.
> >
> > Perhaps this is the point of disagreement.
> >
> > I would expect CAs to offer appropriate pinning advice with
> > certificates, probably in the form of "paste this into your HPKP
> > header". Once a cert is in use and pinned, no further changes to those
> > pins need to be made.
>
>  So you're expecting sites to edit their HPKP header on every cert
>  change?  In that case I'd expect them to pin their end-entity key (see
>  reasons below).  I believe they'd have to edit the HPKP header twice:
>   * Add their next end-entity key to the HPKP header
>   * Wait for time T (where T is sufficient for all older pins to expire)
>   * Switch to certificates with the new key
>   * Once the switch is complete, delete the old key from the HPKP header
>
>  Sound right?
>
>
> > No matter what happens to the CA's business, as
> > long as the root and intermediate you are using are still valid (and,
> > absent a CA breach, they will be - no CA sells certs which use roots and
> > intermediates which expire before the cert finishes its lifetime), you
> > don't have to worry. When you get a new cert (renewal), you'll get
> > updated pinning advice.
>
>  In a strict sense I don't think this is true.  You're assuming every
>  end-entity cert "uses" a single root, which is constant for the
>  lifetime of the cert absent a CA breach.
>
>  But HPKP pins are checked against the browser-constructed cert path,
>  which might contain intermediates and roots different from what the
>  website sent, or thinks its "using".
>
>  Example:  You pin what you think is the root cert of your current
>  certificate.  3 months later the intermediate is upgraded to a root in
>  the browser's trust store, or becomes cross-certified by a different
>  root.  Your pin fails, as the browser no longer constructs paths that
>  use the pinned root.
>
>  See Ryan's explanation of AIA chasing for more on this [1].
>
>  While pinning the end-entity's immediate-parent intermediate doesn't
>  have this problem, I don't see that it has any advantage over pinning
>  the end-entity key directly.

Regardless of what the website sends, there is no question that there is a
single authoritative source for all possible paths - this is the CA
themselves.

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. The CA knows what roots they have that exist (as
they've been audited and part of their CPS), they know what plans they
have for the issuance of new intermediates or the deprecation of older
intermediates, and they can work to communicate that to customers.

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. That is, it is directly because browsers treat all CAs as equal
that a site operated in the US, by a US company, with a certificate from a
US CA, can be compromised by a small organization in the Netherlands.

Pinning, in many ways, restores the balance by allowing the *site
operator* the flexibility to state their security policy, with the input
of their CA, independent of any browser coordination.

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.

For example, most intermediate re-issuance by CAs is done in order to keep
CRLs small or to make modifications of policies. A CA may offer a class of
"pinning" certs specifically designed such that the frequency of these
events is minimized. It's a perfectly reasonable market tradeoff. Perhaps
this will be an extra cost, commisserate to the presumed support costs in
configuring this, or perhaps it will be a free service, as each pinning
reflects a customer's endorsement of a given CA's security policies and
practices.

I see the problems you're raising regarding SPKI as being solvable by
means other than technical, whereas the whole notion of pinning by CA name
opens up a whole host of new problems that can *only* be solved with
increasingly complicated technical solutions and that serve to *remove*
control from site operators, and *increase* the implementation hurdles to
implementors - making it unattractive to both parties.

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.

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.

>
>
> > If you have pinned a backup provider, you will no doubt have sought
> > similar pinning advice from them. There is more of a risk that this
> > advice will need to change at a different time from you changing your
> > cert, but that's OK, because you can change this stuff as much as you
> > like and all you have to do is wait for caches to empty (30 days?).
>
>  Well, you *can* change your HPKP header as much as you like, but do
>  you want to?  If you pin several CAs, and find yourself having to edit
>  the HPKP header multiple times a year, isn't that kind of a hassle?
>
>  My point was not that it's impossible for websites to track CA key
>  lists, just that it would be more user-friendly if they didn't have
>  to.
>
>
>  Trevor
>
>
>  [1] http://www.ietf.org/mail-archive/web/websec/current/msg01425.html
>

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 16 Aug 2013 09:05:57 -0700

On Thu, Aug 15, 2013 at 12:18 PM, Ryan Sleevi
<[email-masked]> wrote:
> 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.

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

> much less churn/turnover than their 'traditional' roots.

That would be great.

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

> 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