F20 Self Contained Change: Remove deprecated calls of using ntpdate in favor of ntpd

Chris Adams linux at cmadams.net
Wed Jul 17 13:36:40 UTC 2013


Once upon a time, Paul Wouters <pwouters at redhat.com> said:
> Additionally, with systems without a realtime clock, like the raspberry
> pi, we have a new problem where we need to obtain the time from an
> external source. That might seem easy, but with DNSSEC, we might not be
> able to resolve pool.ntp.org without first having a time estimate that's
> accurate to about 1 hour.

Have you tried the -q, -g, and -x options to ntpd?

> 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.

> 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.

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.

-- 
Chris Adams <linux at cmadams.net>


More information about the devel mailing list