On Wed, 17 Jul 2013, Chris Adams wrote:
Have you tried the -q, -g, and -x options to ntpd?
Yes, see other email. I saw it and provided we allow large clock skew
providing all 3 options, I'm okay with replacing ntpdate.
I have been thinking about how to solve that properly. One idea is to
use DNS and ignoring the time in the RRSIG records, getting a bunch of
DNSSEC queries from various TLDs and the root, using that to estimate
time, then trying to enable DNSSEC and resolve pool.ntp.org.
Yeah, that's a hard chicken-and-egg problem to solve. Really, without
any real clue of the current time (or a trusted local time source), you
are just at the mercy of the Internet. I'd say just disable DNSSEC for
the initial queries. Anyone in a position to mess with the DNS replies
will also be in a position to mess with the NTP traffic.
That's easiest said then done. It takes a lot of queries before you hit
pool.ntp.org. And then you have to 1) ensure no one else uses those DNS
answers and 2) flush the cache when enabling DNSSEC.
Another alternative could be to use something like tlsdate, which
obtains time from HTTPS servers, but then we would need to use wellknown
servers and rely on the CA PKI. Also, tlsdate really needs a security
review.
You still need a reasonable approximation of the current time to start
with, since certificates have specified validity periods.
Yes, but those validities are in the order of months or years, not 1
hour, as is the case for RRSIG's for .org.
If you have no idea what time it is, you really can't start having
secure conversations with anyone else. You just have to assume somebody
is telling the truth and move forward.
That's why for a simple "reboot", we could save the time to have some
approximation of time when we start (if we have no realtime clock or
see the time is 1970 of 2000)
Paul
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
