Re: [websec] Certificate Pinning via HSTS

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

On 09/14/2011 12:44 PM, Phillip Hallam-Baker wrote:
> On Wed, Sep 14, 2011 at 11:13 AM, Daniel Kahn Gillmor <[e-mail]
>> wrote:

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

I personally like this approach and i use multiple keys for different
hosts serving the same domain for at least one domain i administer
myself.  i also note that it is diametrically opposed to your earlier
stated goal of avoiding "major operational headache", particularly when
using an external CA.  I was trying to offer a way to avoid major
operational headache in my proposal.

Of course, the other way to avoid the headache in this is to use an
in-house CA, but of course that gets back to my "the only reasonable CA
to pin is an in-house CA".

> Keys should be unique to the host and never move from the host.
> 
> It is certainly not just citibank that has that scheme.

Are these other organizations public?  I'm looking to compile a list of
groups that do this to raise this concern with the
Convergence/Perpsectives folks, since these always show up as bad under
their model of analysis.  Feel free to mail the the list privately if
you don't want to publish it, or if you feel it is off-topic for this list.

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

You're asking me to assume a whole stack of things about operational
integrity, access control, system maintenance, and coding practice at
various CAs.  I have no idea whether any of these things are true for
any CA in particular.  All i know is that there is a CA that is
nominally under the control of a separate organization.

I'd happy if someone could prove that these intermediate CAs are
actually all locked down under very high security and properly limited
in what kinds of certificates they can issue; but i'm not convinced such
a proof is possible.

And given the recent events, i'd have no confidence in an unproved
assertion of secure operations of these subordinate CAs.

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

The draft as initially proposed included both explicit mechanism and
several "best practice" recommendations (e.g. pin rollover and backup).
 I think these recommendations were good ones, and contribute a lot
toward making the draft clear and useful to the people who will have to
deploy the mechanism.

If this becomes an RFC, i'd hope these recommendations would persist in
a "SECURITY CONSIDERATIONS" section or the equivalent.

I'm proposing an additional recommendation: unless you control and
operate your own CA, you probably only want to pin EEs.

Regards,

	--dkg