Time synchronization issues

[Roger Dingledine <arma@mit.edu>]

Time sync bugs have starting to come up now that we're adding new routers
to the network. The current bug is that the new router's system time is
a few seconds (or sometimes 10 hours) after mine. It creates its x.509
cert, connects, and hand the cert to the dirservers; they freak out
because the cert was created in the future.

What's the right answer to this? Currently I've got a patch to tortls.c
which slides "now" back and forth a couple hundred seconds in between
calls to things like X509_cmp_time(X509_get_notBefore(cert), &now),
to handle some minor slop.

But what about major slop? Like, one of our servers had his clock several
hours off, today, and he wasn't allowed to connect to the network. His
original descriptor is still being considered "newest" by the dirservers:
they're rejecting all his updates because they're older (now that he's
fixed his clock).

Will the world end if we tolerate certificates that are wrong by, say,
a whole day? What do other systems do here? What's the point of the
timestamp checking on the certs, in terms of our threat model?

And the broader question: when we are unhappy at a TLS peer and hang
up on him, he has no idea why we hung up. It occurs to me that we've
already handshaked by this point, so we could send a "failed" cell with
a payload which describes why we're hanging up on him. Is this a good
idea or a bad idea?

--Roger