DNSSEC validation without current time

Timothe Litt litt at acm.org
Fri Dec 15 14:51:03 UTC 2017


On 15-Dec-17 06:45, Petr Menšík wrote:
> Hi folks.
>
> I am looking for a way to validate name also on systems, where current
> time is not available or can be inaccurate.
>
> This is related to booting with NTP client, when the only configuration
> is hostname that has to be resolved. There is a bit circle dependencies.
> First current time is required for DNSSEC validator to verify signatures
> of all keys. However that is hard to maintain on systems without RTC
> clock running when it is down. Raspberry PI is example of such system.
> Until hostname is known, time cannot be synchronized and corrected to
> real value. They sort of depend on each other. The only secure way I
> found is to hardcode IP address into NTP client or obtain IP from other
> trusted source (DHCP?).
>
> Available option is of course to disable validation until valid time is
> received. It seems to me that is unnecessary lowering the security. I
> would like some option to limit checking validity period of used keys
> instead. Just validate existing keys from trust anchor and trust the
> last key that can validate. I think that is far better than no
> verification at all.
>
> Is it possible to do that in BIND? Maybe bootstrap verification could be
> done only with delv tool with time-checking disabled. I found no way to
> do that. Is there good reason why it is not available? Is better method
> for solving secure configuration of timeless system available?
>

I added an RTC to my Pis :-)  It makes life a lot simpler, even after I
wrote a driver and calibration mechanism.

But if you have access to a DHCP server, have the client request Option
42; this returns one or more NTP servers' IP addresses in preference
order.  You can use NTPD (or ntpdate) to get a time.   ISC DHCP client
supports this option; see dhcp-users if you need help.

DNSSEC requires reasonably accurate time, as signatures have validity
periods.  Your scheme would not work; you need time to validate ANY
signature - from the trust anchor down.  If there's no time, you can't
validate any part of the chain - so you might as well use ordinary DNS. 
NTP is fairly robust; it uses consensus from multiple servers to
establish correct time.  For a rogue DNS to inject bad time into your
PI, it would have to know which NTP servers you are using.

Another option is to use DHCP to get the address of a validating
resolver, and rely on that for bootstrapping NTP.  Again, this depends
on whether your control/trust your DHCP server.  More ISPs are providing
validatiing DNS server, but it's not universal. Hardcoding one of the
public ones (e.g. Google - 8.8.8.8, 8.8.4.4, 2001:4860:4860::8888,
2001:4860:4860::8844) is fairly safe. 

NTP server addresses are more volatile, and it's a serious breach of
netiquette to hardcode them; there are a number of stories of how this
has gone badly wrong for all concerned.

The choice depends on your requirements, available resources, and risk
tolerance.

You also need valid time for many other applications; TSIGs require a
reasonably close (on the order of minutes) time sync between sender and
receiver.

So rather than try to tweak NAMED, focus on getting a reasonable time
early in boot - and make sure that dependencies on a valid time are
properly expressed in your startup scripts.

Bottom line: your problem is getting a reasonable time, not with the
consumer(s).

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/20171215/0164e390/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4577 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20171215/0164e390/attachment-0001.bin>


More information about the bind-users mailing list