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

[Trevor Perrin <[e-mail]>]

On Thu, Aug 15, 2013 at 1:30 AM, Gervase Markham <[e-mail]> wrote:
> On 15/08/13 09:20, Trevor Perrin wrote:
>> So you're expecting sites to edit their HPKP header on every cert
>> change?
>
> No; it's quite possible that the advice on renew would be "keep the same
> pins".

OK.  So you're expecting sites to request a new cert at least T days
prior to their existing cert expiring (where T is the length of time
needed for extant pins to expire).

The CA will inform them whether any new keys need to be added or
removed to the HPKP header, based on knowledge of their previous
header.

If new keys need to be added, the site will then go through an update
process like I described before:
 * Add the new keys to the HPKP header
 * Wait for time T (where T is sufficient for all older pins to expire)
 * Switch to new certificate
 * Once the switch is complete, delete any old keys from the HPKP header

Is this right?


> And I'd expect the CA to talk about the trade-offs with the customer
> before offering their best advice for the customer's situation.
>
>>  * 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?
>
> Pinning to an end-entity key is indeed more work.

Pinning to an end-entity key requires an update process on every key change.

Pinning to root keys requires an update process less frequently.  But
the process is of similar complexity.


> I suspect that for
> most sites, the best trade-off will be pinning to two or three roots,
> one from each of two or three different CAs, where the CA has told them
> "yes, we issue certs from this root for sites like you, and will
> continue to do so for the forseeable future".

I suspect most sites would prefer to pin more CAs, for safety's sake.
But I could be wrong.

It would be be nice if each CA is able to indicate a single key for
the customer.  But I'm not sure if that's feasible or excessively
risky.


>>> 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".
>
> That is true; however, a CA should be aware of the possible different
> constructible paths, and provide pinning advice which takes them into
> account.

Sure.  But how paths for a *single* cert are constructed can change
over time, independent of new cert issuance, which you're not
accounting for.


>> 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.
>
> In this scenario, you seem to have failed to consult your CA for advice
> on how best to pin to their chain :-)

No, they gave you correct advice at the time of issuance.  The root
key pin was sufficient.

But things changed (due to, say, merger or business relationship
change between CAs).


Trevor