<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-2">
</head>
<body text="#000000" bgcolor="#FFFFCC">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 18/12/2017 14:44, Timothe Litt
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:bac9942b-14b0-2fe4-b310-76c38b4801a2@acm.org">
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-2">
<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>
</blockquote>
True but look at it this way, first get a guess on the time from
"an" NTP server, then try using that time to get DNSSEC replies, if
they work, the time was good enough, if the time was bad, DNSSEC
will not work and you know you have a bad time,and will have to try
again or die.<br>
<blockquote type="cite"
cite="mid:bac9942b-14b0-2fe4-b310-76c38b4801a2@acm.org"> <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"
moz-do-not-send="true">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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Please visit <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list
bind-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
</pre>
</body>
</html>