Re: [websec] Certificate Pinning via HSTS

[Daniel Kahn Gillmor <[e-mail]>]

On 09/14/2011 09:46 AM, Phillip Hallam-Baker wrote:
> It gives you scaling and administrative convenience.
> 
> If you have 10,000 hosts in your enterprise network you really do not want
> to have to be managing trust on a per host level.

You're not "managing trust on a per host level" -- you're managing
*identity* on a per-host level, which is exactly what it should be.  If
you have 10K hosts, you need to think clearly about the identity
presented by each of those hosts.

> Now consider the case
> where you are renting your compute power in the cloud and so the machine
> instances are existing for a few hours at a time.
>
> Any scheme that insists on only tying to the EE cert or key is going to
> create a major operational headache for those sites. It is really easy to
> design a scheme that is easy to administer.

is it more of an operational headache to get an external CA to sign a
new key for each host each time it comes up "for a few hours"?  or to
just push the relevant pre-existing keys+certificates onto the hosts in
question?

> It is also going to cause huge amounts of state that the client has to
> manage. If you have 10,000 front end web servers you are going to need
> 10,000 different client keys to do the job right.

eh?  why?  if these are front-end web servers hosting the same service,
wouldn't they just share a key (and a certificate)?  The only large
organization i know of that uses one key per server is citibank, and
many people are making decent arguments that this is problematic for
other methods of identity verification (e.g. Perspectives and
Convergence plugins)

> So what most of the large enterprises would likely do if they introduced any
> form of security policy would be to have a private CA run up that is an
> intermediate in a larger hierarchy.

Sure, as i pointed out, the only reason you'd want to pin a CA is if the
CA is under your own organization's direct control.

> This is why the bogus EFF study came up
> with the absurd number of 600 CAs. What they have never come clean on is the
> fact that 150 of those 'CAs' are in fact merely intermediate roots tied to a
> single customer that are managed in the same infrastructure as the root CA
> operations.

if those intermediate authorities are not explicitly domain-restricted
*in their own certificate*, then yes -- the risk is larger.  i don't

> What pinning to a CA does raise is the absolute need to have the ability to
> pin more than one CA at a time.

i think for rollover purposes, you already need to be able to pin
multiple certs if you're pinning an EE.

Still unconvinced,

	--dkg