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

["Ryan Sleevi" <[e-mail]>]

On Thu, August 15, 2013 1:20 am, Trevor Perrin wrote:
>  On Wed, Aug 14, 2013 at 4:44 PM, Gervase Markham <[e-mail]> 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
>