DNSSEC validation without current time
Sten Carlsen
stenc at s-carlsen.dk
Mon Dec 18 17:24:20 UTC 2017
On 18/12/2017 14:44, Timothe Litt wrote:
>
> 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.
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.
>
> * 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.
>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20171218/0deea870/attachment.html>
More information about the bind-users
mailing list