Re: Time synchronization issues

["Joel N. Weber II" <ordev@joelweber.com>]

So, if you're trying to design a system that's secure, the real issue
to worry about is whether there are circumstances where an attacker
can manipulate clocks to be able to use a certificate that's invalid.

If you're really relying on the clocks being accurate, then you need
to have documentation that says to people running onion routing
software, ``don't configure your computer to use rdate -s
trusted-time-server.example.com every time it boots, for any protocol
such as rdate which is not cryptographically authenticated.''  (This
sort of thing is not entirely obvious; for a couple years I was
running a kerberos kdc which did essentially that, and even though
this sort of thing is probably more critical for kerberos than it is
for onion routing, I was completely oblivious for a while to where it
could be a potential security hole.)  And there are other ways to get
unauthenticated time than at boot time, so the documentation needs to
be somewhat more general than what I just said.

Certificate expirations are generally set up to be like once a year or
so, and if you allow a day of slop, that's about .3%, which is tiny
compared to the arbitraryness of choosing a year rather than some
other amount of time.  I don't believe allowing a day of slop will
substantially change the security properties vs not allowing a day of
slop.

But the real question is ``how do you deal with making sure that old
keys can die?''  Secure time sync can be challenging; an application
generally can't get any sense of how well authenticated the host's
idea of the current time is.  And you can probably argue that doing
on-line verification that a cert is unrevoked requires about as much
infrastructure as secure time sync (you need a reachable secure host
that you can talk to in real time to verify some information from).

And at some point, you'll have a compromised private key that you'll
want to revoke, long before it expires.  How are you going to handle
that?  And can you use the same mechanism to revoke keys that are
expired so that clock sync doesn't matter?

Does a typical web browser/web server allow more slop than openssl
supports by default?  If not, why is it that this is such a big
problem for onion routing?  Why can't people just be told to fix their
clocks?  (Yes, the error should make it obvious that that's the
problem, ideally.)