ietf
[Top] [All Lists]

Re: Practical issues deploying DNSSEC into the home.

2013-09-10 11:11:17
On Tue, 10 Sep 2013, Jim Gettys wrote:

We uncovered two practical problems, both of which need to be solved to enable 
full DNSSEC deployment into the home:

1) DNSSEC needs to have the time within one hour.  But these devices do not have TOY 
clocks (and arguably, never will, nor even probably should ever have them).  

So how do you get the time after you power on the device?  The usual answer is "use ntp". 
 Except you can't do a DNS resolve when your time is incorrect.  You have a chicken and egg
problem to resolve/hack around :-(.

Securely bootstrapping time in the Internet is something I believe needs doing.... 
 and being able to do so over wireless links, not just relying on wired links.

One solution is "tlsdate" which uses the installed bundled CA (or comes
with its own) and runs TLS against a bunch of well known large sites
(using insecure DNS) and sets the time based on the TLS handshakes.

2) when you install a new home router, you may want to generate certificates 
for that home domain (particularly so it can be your primary name server, which 
you'd really like to be under
your control anyway, rather than delegating to someone else who could either 
intentionally on unintentionally subvert your domain).  

Right now, on that class hardware, there is a dearth of entropy available, 
causing such certificate generation to be painful/impossible without human 
intervention, which we know home
users don't do.  These SOC's do not have hardware RNG's, and we can't trust them 
either blindly. Ted's working on that situation in Linux; it is probably a case of 
"the enemy of the good
is the perfect", but certainly I'm now much more paranoid than I once was.

Be aware openwrt has a history (with openswan) to blindly change
/dev/random references into /dev/urandom. You are most likely better of
giving the device a webgui and using the clients javascript to generate
randomness. (yes I know, I just said to use javascript for private keys)

But I'm still thinking of a scheme involving insecure ntp lookups for
pool.ntp.org, then using inception times of RRSIGs of TLDs to narrow
down the current time. Of course, all of that is vulnerable to replay
attacks.

Also, I believe the rasberry pi's, having the same problem, have a
"hwclock" service that saves a timestamp on shutdown to the filesystem
and loads it on boot. That solves the issue for quick reboots.

Another method is the last access time of the filesystem. But I'm not
sure if that's a linux/ext4+ only feature, or whether the filesystems
in embedded devices have a similar value stored somewhere.

Paul