Re: [websec] Certificate Pinning via HSTS

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Sep 14, 2011 at 11:13 AM, Daniel Kahn Gillmor <[e-mail]
> wrote:

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


Identity is a property of the site, the host is merely an implementation
detail.




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


I really hate having private keys move off a host.

If people are going to be doing that pattern of hosting I would prefer to
have keys tied to the virtual hosts such that they are generated in place
and never ever move from the host. Then have certs generated with short
lived expiry (36 hours), that way the attack surface is kept to a bare
minimum.



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


Keys should be unique to the host and never move from the host.

It is certainly not just citibank that has that scheme.


>

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


Not if the signing keys are in the same hardware module as the intermediate
they are signed under.

The problem is that PKIX policy constraints don't really have the leverage
they should in the real world. And even if they did they don't necessarily
map to real world organizational divisions. A large organization will
typically own many DNS names.

The issue is where validation is performed and if the RA has independent
issue authority or not.

At this point the government of Iran has solved that particular problem.



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


It is an operational issue. There is practically no difference in the code
between only checking the EE cert or key and checking intermediate
certs/keys.

Designs should be as simple as possible BUT NO SIMPLER.

The 'I don't see the need, therefore I will obstruct feature X' approach is
the reason that PKIX has become what it is. We could have had policy
constraints and cross certificate mechanisms that really worked the way we
wanted if they had been baked in on day one. Instead they have become a
black art which can be practiced by a very small circle of people and even
they will tell you how broken the system is.

Give operators the tools to do their job, do not presume to tell them how to
secure their systems.

-- 
Website: http://hallambaker.com/