Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Simon Kelley <simon@thekelleys.org.uk>]

On 22/03/14 17:42, Dave Taht wrote:
> On Sat, Mar 22, 2014 at 3:33 AM, Joseph Swick <cerowrt@decoy.cotse.net> wrote:
>> Hi List,
>> I've been lurking for several months now on the list and I remember some
>> discussion about trying to find acceptable methods for bootstrapping the
>> local system time so that DNSSEC would work.
>>
>> I recently got around to updating my router a week or two ago from 3.7.?
>> to 3.10.28-16 because Comcast finally switched on IPv6 for my neck of
>> the woods (realized this when I finally noticed the performance impact
>> of the issues with Comcast IPv6 and the 3.7 release) .
> 
> I reallly, really, really want to get the comcast users off of 3.7.x. That bug
> is rather severe.
> 
>> Tonight, I went
>> and reset my configuration this evening to clear out some mistakes I
>> made (that was keeping IPv6 from working).  Then I noticed that was
>> getting SERVFAIL for some domains (e.g.: bufferbloat.net) and not others
>> and (in trying to keep this short) I finally remembered to check the
>> clock on the router and saw that it was set to Feb 24th instead of the
>> correct time & date.
>>
>> Is the current recommendation still to put in a couple of IPs for NTP
>> servers into the config of the router?  Or has there been more work
>> towards resolving the NTP bootstrap issue in the more recent releases?
> 
> There has not (as yet) been any work put into resolving the thorny
> ntp/dnssec interrelationship problem. (famous bug #113 in the cerowrt
> database). (Not having
> been running any releases for long enough for it to become a problem made it
> slip my mind!)
> 
> There WAS a bug in openwrt's ntp which led to only one ntp server being queried,
> rather than the default 4. This was fixed several releases back. So
> you failed to
> get a valid time from the one ntp server you saw, and things degraded
> from there.
> 
> The ntp servers queried presently largely are not dnssec signed, so
> the ntp queries
> should succeed (I think?) 

Not necessarily. If DNSSEC is configured to ensure that unsigned domains
are real unsigned domains, then that requires proof-of-noexistence of
the relevant DS records, and therefore accurate time.

To solve this, we need a handle on why inception and expiry times were
added to the DNSSEC protocol. My guess is that it's to avoid use of old
keys which have been rendered insecure by the passage of time (any key
can be cracked or compromised, given enough time.)

One possibility would be to store the current time in NVRAM. When the
router comes up, that gives a lower bound on the current time, and would
 solve attacks using old keys.



in the general case. However, for
> robustness, I'd argue for enhancing the ntp startup script to
> temporarily disable dnssec until it gets a valid time, and then
> enabling it. I believe support for running the script was added to
> busybox ntp, the problem  remaining is how to tell dnsmasq about it
> correctly.

Less drastic would be to disable the key-time checks for this phase.
Simplest would be a config flag: start it up with that flag whilst NTP
does its stuff, them restart without when the clock is OK. Another
option would be to disable the checks when the query arrives from a
"magic" loopback address: maybe 127.110.116.112 (127.'n'.'t'.'p')



Cheers,
Simon.

>