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

[Paul Wouters]

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