DNSSEC validation without current time

[Timothe Litt]

On 18-Dec-17 01:07, Dave Warren wrote:
> On 2017-12-15 06:23, Petr Menšík wrote:
>>
>> Dne 15.12.2017 v 13:06 G.W. Haywood via bind-users napsal(a):
>>> Hi there,
>>>
>>> On Fri, 15 Dec 2017, Petr Men??k wrote:
>>>
>>>> ... current time is not available or can be inaccurate.
>>>
>>> ntpdate?
>>>
>> Sure, of course. What would be default host after installation, that can
>> be used in default installation image without manual configuration? And
>> how does it resolve that name, when date of the system is 1970-1-1 or
>> something a only a bit more accurate?
>>
>> Current pool.ntp.org adresses are unsigned now, so that would work
>> anyway. If I want spoof protection, what should I do?
>
> 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.
>
> 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.
>
> 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.
>

This proposal is involved, but doesn't seem to robustly solve the problem.

  * 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.
  * 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.
  * 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.
  * To prevent DNSSEC from working, time error has to be quite large. 
    All that's necessary is some approximation that's accurate within
    minutes.
  * 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.
  * 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. 

None of this is news.  See
https://tools.ietf.org/id/draft-mglt-dnsop-dnssec-validator-requirements-06.html#rfc.section.5


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.

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 -
https://www.adafruit.com/product/3386 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.)

Alternatively, as previously discussed, if you need the best (non PTP)
time, add a GPS receiver, with pool backup.

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.

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.

As previously noted, startup scripts need to have the "right" definition
of "system time available" & dependencies for your applications
(including named) to start.

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.

So, what to conclude?

  * 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.
  * 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.
  * If you also want precise time, but don't need it to be highly
    available, add a GPS.
  * For more availability, do both.  And possibly add other time sources
    (Radio, TCXO, geographically dispersed GPS, more RPis...).

In any case, let us know what you end up with.

Have fun!

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


    rtc/rtc-ctl --show --debug
    TOY Clock registers as read (UTC):
    81: 57 RUN 57 sec
    83: 42     42 min
    85: 12 24H 12 hr
    87: 18     18 date
    89: 12     12 month
    8B: 02     02 weekday
    8D: 17     17 year
    8F: 80  WP ctl
    Applying drift correction of -28.370 PPM to 10869574.837 seconds
    (125d 19h 19m 35s) elapsed
    TOY    time is Mon Dec 18 2017 07:48:05     EST
    System time is Mon Dec 18 2017 07:48:07.234 EST
    Remaining offset is -2.234 sec (-0.206 PPM)

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

Oh, why mention TSIG?  Because ... it's another time-sensitive part of
named, and often used for DHCP - DNS updates...

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20171218/25988690/attachment.html>