[SSL Observatory] Diginotar broken arrow as a tour-de-force of PKI fail

[Peter Gutmann]

Rob Stradling <rob.stradling at comodo.com> writes:

>Would a "something else" certificate status checking protocol that requires
>Clients to do secure time sync (instead of requiring nonces) get your
>blessing?

It's hard to say without getting more data on it.  We know (see my earlier
post on this) that PC clocks are all over the place (including being out by
days, months, and even years).  Including time in the TCB has been a long-
standing flaw of almost every PKI protocol ever created, with all protocols
simply assuming that everything that would ever touch a cert had a magically
sychcronised clock.  In the case of SSL/TLS, the client actually tells an
attacker how far out its clock is in the ClientHello.  This does not seem like
a good combination.

I would really like to see a proper threat model for this.  What are we
defending against?  For example given that an attacker who compromises a CA
can add their own AIA to the fraudulent certs it mints that point to an
attacker-controlled responder with another fraudulent cert that
"authenticates" any response (or simply leave out the AIA, so there's no
responder to check), it doesn't matter what the rest of the infrastructure
does.

Because of that, how strong does the validity-checking actually have to be?
After years of various people fighting to get OCSP fixed, I managed to get a
completely different validity-checking mechanism through as a PKIX standards-
track RFC:

  http://www.ietf.org/rfc/rfc4387.txt

but only because I disguised what it actually does sufficiently that it's not
obvious to people what you can really do with it.  At some point I was going
to publish an addendum, "Using ... for Certificate Status Checking".  Since
this is built on top of standard HTTP, it should scale as well as any other
bit of HTTP infrastructure (via distributed cacheing and CDNs and whatnot),
and can use other mechanisms like Last-Modified and so on.  If an attacker
compromises a CA (i.e. what we've been experiencing now), the mechanism is no
weaker than any other, and it has the benefit that it's scalable.  The RFC
also provides an alternative mechanism to requiring an AIA in an attacker-
controlled cert.  Oh, and the RFC is already published and standards-track
:-).

So I'm really responding to your question with another question: What's your
threat model?

Peter.