<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-2">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 18-Dec-17 01:07, Dave Warren wrote:<br>
</div>
<blockquote type="cite"
cite="mid:%3C7f2d412e-61f0-6a9c-4fea-52665f03a2a1@thedave.ca%3E">On
2017-12-15 06:23, Petr Menšík wrote:
<br>
<blockquote type="cite">
<br>
Dne 15.12.2017 v 13:06 G.W. Haywood via bind-users napsal(a):
<br>
<blockquote type="cite">Hi there,
<br>
<br>
On Fri, 15 Dec 2017, Petr Men??k wrote:
<br>
<br>
<blockquote type="cite">... current time is not available or
can be inaccurate.
<br>
</blockquote>
<br>
ntpdate?
<br>
<br>
</blockquote>
Sure, of course. What would be default host after installation,
that can
<br>
be used in default installation image without manual
configuration? And
<br>
how does it resolve that name, when date of the system is
1970-1-1 or
<br>
something a only a bit more accurate?
<br>
<br>
Current pool.ntp.org adresses are unsigned now, so that would
work
<br>
anyway. If I want spoof protection, what should I do?
<br>
</blockquote>
<br>
Do two passes. First: Use DNS without DNSSEC validation to obtain
a list of NTP servers, and thereby determine the current time.
Second: Use DNS with DNSSEC to obtain a list of (trusted) NTP
servers, and verify the time.
<br>
<br>
The second pass might detect the list of IPs has changed and
bypass the second NTP pass as we now know the previous IPs were
valid, but you must be prepared for DNS to return different IPs
from a pool and to therefore re-verify the time -- We don't care
if the IP list has changed, only that the time is valid.
<br>
<br>
The only real challenge is to avoid letting anything else trust
the time received in phase 1 until it has been validated by phase
2.
<br>
<br>
</blockquote>
<br>
This proposal is involved, but doesn't seem to robustly solve the
problem.<br>
<br>
<ul>
<li>Pass 1 obtains "current time". But you don't trust that the
IP addresses of the NTP servers were correctly resolved. So you
don't trust this time. However, you need a reasonably
trustworthy time to bootstrap DNSSEC. (On the order of
minutes). Else DNSSEC validation can fail.<br>
</li>
<li>If you're using the pools (and they resolve correctly), you're
pretty much guaranteed that any two queries will produce a
different set of servers. So IP addresses will change.</li>
<li>If you use a reasonable number of NTP servers and NTP (not
SNTP) protocol, invalid timekeepers will be sorted out. NTP is
quite robust, and expects some variance - including some
malicious actors. The reasonably recent versions with pool
support will discard bad timekeepers and keep drawing from the
pool until consensus is attained. And again if it's lost (e.g.
some go bad due to system or network failures.) To fool NTP,
you need to provide a number of bad time sources, synchronized
closely enough for NTP to accept them. This is non-trivial.
Suppose someone puts in that effort and succeeds. What
happens? DNSSEC is the least of your problems. Other breakage
will be more subtle. Like filesystem times being inconsistent
and breaking CMS and other applications.<br>
</li>
<li>To prevent DNSSEC from working, time error has to be quite
large. All that's necessary is some approximation that's
accurate within minutes.</li>
<li>Pass 2 requires "trusted" NTP servers. If you have that list,
why not resolve those names without validation in the first
place? You could assume that a hostile actor knows which names
you resolve, and assume that they will substitute bad
timekeepers. But if they can do that, they can do the same for
the pools' names.</li>
<li>What can bad time do to DNSSEC? By rolling back, it could
allow validation of an expired signature - but the attacker
would have to be able to benefit from that. Or it could prevent
validation of a current signature (by making current time be
outside the validity period). Or it could prematurely force you
to validate a published, but not yet active signature. These
amount to (at worst) denial of service. <br>
</li>
</ul>
None of this is news. See <a
href="https://tools.ietf.org/id/draft-mglt-dnsop-dnssec-validator-requirements-06.html#rfc.section.5">https://tools.ietf.org/id/draft-mglt-dnsop-dnssec-validator-requirements-06.html#rfc.section.5</a>
<p>The bottom line is that you want accurate time. And if you have
accurate time, DNSSEC will follow. You also need to consider the
threat profile that you face - including the downside risks and
costs of a defense.<br>
</p>
Bootstrapping requires some reasonably accurate time source. The
easiest way to get there is with a locally trusted source. You can
add an RTC - again, here's one from Adafruit - <a
moz-do-not-send="true"
href="https://www.adafruit.com/product/3386">https://www.adafruit.com/product/3386</a>
about $5 (US). [Same disclaimer.] The RTCs (I haven't run this
one) in general have poor accuracy(2) - but if resynchronized with
NTP time once in a while, easily good enough to bootstrap DNSSEC.
The one I use (1) is good to less than 1PPM with the help of some
drift compensation that I put into the utility that manages the
clock. [It's a replacement for 'hwclock' that drives this RTC.]
(This reduces the jump when NTP starts, and helps keep logs
straight. If you don't care about that, just update the RTC from
NTP time every week or two - that's more than sufficient for DNSSEC
& NTP bootstrap.)<br>
<br>
Alternatively, as previously discussed, if you need the best (non
PTP) time, add a GPS receiver, with pool backup.<br>
<br>
You can skip the DNS cyclic dependency completely if you have
locally-trusted NTP and DHCP servers - provide your clients with the
NTP server addresses via DHCP. (They're sent as IP addresses, not
names.) This isn't as hard as it appears. If you run NTP on all
your machines (yes, there's NTP for windows), your Pi can get time
from them.<br>
<br>
Further, since you run your own DNS server - presumably within some
firewall - you can trust it to serve your local zones. DNSSEC not
required. If you include your local machines in your NTP
configurations, everything is under your control. It then becomes a
sequencing issue only if your entire site goes down. (If so, you
want your local master to be up first. Otherwise, the rest will
coast using other NTP sources.) If you're really serious, you run
at least 3 local clocks - preferably something like GPS, WWV (or
other radio source), and a local atomic (or at least, TXCO) clock.
If you start looking at failure scenarios, it gets more interesting.<br>
<br>
As previously noted, startup scripts need to have the "right"
definition of "system time available" & dependencies for your
applications (including named) to start.<br>
<br>
Because the draw minimal power (and so will run a long time with a
modest UPS), I use an RPi with GPS & some pool servers as my
preferred time source. It boots using an RTC. My edge router also
runs NTP, preferentially taking time from the RPi - but also
configured with other Public and local servers. In case the RPi
goes down, the local machines also participate - the low latency and
dispersion pretty much ensures that they'll be taken over the public
servers. I may add another Pi with another GPS and/or radio
receiver, when I acquire enough round TUITs.<br>
<br>
So, what to conclude?<br>
<ul>
<li>If you have other machines in your local network, use them as
NTP sources and provide the addresses to your RPi via DHCP.
This is cheapest and easiest.</li>
<li>If you don't need precise time (e.g. for purposes beyond
DNSSEC), the next cheapest solution (in $ and time) is to just
add an RTC.</li>
<li>If you also want precise time, but don't need it to be highly
available, add a GPS.</li>
<li>For more availability, do both. And possibly add other time
sources (Radio, TCXO, geographically dispersed GPS, more
RPis...).</li>
</ul>
In any case, let us know what you end up with.<br>
<br>
Have fun!<br>
<br>
(1) This isn't an expensive problem to solve. My RPi's RTC (TOY)
uses a DS1302 - I got a bunch from e-bay for about $2 (including
battery & shipping). I could publish the software if there's
interest.<br>
<blockquote>
<tt><br>
</tt><tt>rtc/rtc-ctl --show --debug<br>
TOY Clock registers as read (UTC):</tt><tt><br>
</tt><tt>81: 57 RUN 57 sec</tt><tt><br>
</tt><tt>83: 42 42 min</tt><tt><br>
</tt><tt>85: 12 24H 12 hr</tt><tt><br>
</tt><tt>87: 18 18 date</tt><tt><br>
</tt><tt>89: 12 12 month</tt><tt><br>
</tt><tt>8B: 02 02 weekday</tt><tt><br>
</tt><tt>8D: 17 17 year</tt><tt><br>
</tt><tt>8F: 80 WP ctl</tt><tt><br>
</tt><tt>Applying drift correction of -28.370 PPM to 10869574.837
seconds (125d 19h 19m 35s) elapsed</tt><tt><br>
</tt><tt>TOY time is Mon Dec 18 2017 07:48:05 EST</tt><tt><br>
</tt><tt>System time is Mon Dec 18 2017 07:48:07.234 EST</tt><tt><br>
</tt><tt>Remaining offset is -2.234 sec (-0.206 PPM)</tt><tt><br>
</tt></blockquote>
(2) 20 ppm is ~ one min/month. Typical crystals can be 100 ppm or
more (depending on temperature & PCB layout), so 5 min/month.
TSIG fudge is nominally 5 min, so resyncing every 1-2 weeks is close
enough. And also close enough for sane DNSSEC configurations. You
can resync more often, but it's a fair bit of bit-banging on a slow
bus (I2C or SPI for most), and there's no point.<br>
<br>
Oh, why mention TSIG? Because ... it's another time-sensitive part
of named, and often used for DHCP - DNS updates...<br>
<br>
<pre class="moz-signature" cols="72">Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
</pre>
</body>
</html>