Re: [websec] Certificate Pinning via HSTS

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

On Wed, Sep 14, 2011 at 1:38 PM, Daniel Kahn Gillmor
<[e-mail]>wrote:

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

Not really. Operating infrastructure on a large scale, the issue is not the
number of operations required but the number of interdependencies between
systems.

Having keys that never leave the machine eliminates a lot of the management
issues to do with equipment that is lost, stolen etc with the keys loaded.
If you have 10 machines it is pretty obvious that you have lost one. On a
large installation racks of equipment can be appearing/disappearing on a
bewildering basis. And it is not uncommon for theft to be an insider who is
selling off machinery that is being booked as destroyed.


The way I would ideally lock a key to a host is to have a permanent host key
that is unique to that device and only used for authenticating cert
requests. To instantiate an instance of some server the data center pushes
out the server image and a one time use authentication key that is used to
authenticate a cert request for that specific machine. The host generates a
new key per cert request.

That approach allows a system where all the data flows are unidirectional,
no three way synchronization etc.



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


We can get to agreement on a 'house specific CA'.

Running it in-house is a pain and is going to get worse over time as the
criteria for public CAs are raised by the browser providers.

Where I think we might want to shoot for with this would be to look for dual
control points and a key splitting type approach.


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


I would think that would be proprietary and customer confidential and I
would have to ask a former employer.

It is easier to measure than make the request. Just look for companies that
have multiple A records and then see if they have the same cert or not.


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

No, it is not a CA, according to the defined terms, the CA performs the
validation and signature function. If there are 150 keys in one HSM they are
under control of one CA, not 150.

The fact that a CA issues some certs for a given customer off a different
intermediate to their other customers does not increase the number of
signing parties.

Such a customer might well have had a local RA capability, but that should
have been locked down so they could only issue for their roots. At this
point I very much doubt that there are any such RAs being operated as a true
RA without the CA performing full validation of the requests. Thank the
Iranian government for that change in practice.

There is a slight difference in the trust model in that such an intermediate
root can be and is frequently used to provide authorization data. This is
mostly used for client certs. But if the proposal being discussed here went
through there would be a real value to the key splitting approach outlined
above for servers.

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

It is the job of the certificate policy requirements to make those demands
explicit and of the auditors to ensure that they are enforced.

One of the reasons that Comodo has been pushing to introduce baseline
requirements for all public CA issued certs is to get some controls into the
system that can be checked by auditors.

We have these requirements for EV certs, until recently we did not have the
requirements for DV certs.


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


It definitely needs to be audited. But we definitely need to have additional
controls that can be used when the auditors don't do their job.

The fact that the Diginotar root was revoked has woken up anyone who still
needed it.


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

That is fine.

I think we can write a set of security considerations that are pretty much
the advice you give and direct them at the smaller to medium sites that turn
SCs into operational policy.



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

How about we split the difference? We can leave in control. Just take out
'operate'.

My preference for the larger enterprise would be a split key approach. That
reduces my liability and risk.

By the time this is all through I think the number of people still willing
to operate CAs is going to be a much smaller set than in the past.


Regards,
>
>        --dkg
>
>


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