OpenID/Debian PRNG/DNS Cache poisoning advisory

[Perry E. Metzger]

"Ben Laurie" <benl at google.com> writes:
>> It's easy to compute all the public keys that will be generated
>> by the broken PRNG. The clients could embed that list and refuse
>> to accept any certificate containing one of them. So, this
>> is distinct from CRLs in that it doesn't require knowing
>> which servers have which cert...
>
> It also only fixes this single type of key compromise. Surely it is
> time to stop ignoring CRLs before something more serious goes wrong?

The problem is, the CRL mechanism itself is also dangerous.  Sadly,
clients are required to keep on going if they can't reach a CRL
server. That means that if you DoSing the CRL servers or use DNS
attacks to effectively take them offline, you've also effectively
eliminated the certificate revocation.

I'm not going to tell you that paying attention to CRLs wouldn't be
better than what happens now, but it will not eliminate the
problem. It is too hard to "prove a negative" (that is, to prove to
yourself that no revocation exists.)

The kerberos style of having credentials expire very quickly is one
(somewhat less imperfect) way to deal with such things, but it is far
from perfect and it could not be done for the ad-hoc certificate
system https: depends on -- the infrastructure for refreshing all the
world's certs every eight hours doesn't exist, and if it did imagine
the chaos if it failed for a major CA one fine morning.

One also worries about what will happen in the UI when a certificate
has been revoked. If it just says "this cert has been revoked,
continue anyway?" the wrong thing will almost always happen.

Perry
-- 
Perry E. Metzger		perry at piermont.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com