Practical issues deploying DNSSEC into the home.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ted T'so referred to a conversation we had last week. Let me give the background.

Dave Taht has been doing an advanced version of OpenWrt for our bufferbloat work (called CeroWrt http://www.bufferbloat.net/projects/cerowrt/wiki/Wiki).  Of course, we both want things other than just bufferbloat, as you can see by looking at that page (and you want to run in place of what you run today, given how broken and dated home router firmware from manufacturers generally is).  Everything possible gets pushed upstream into OpenWrt as quickly as possible; but CeroWrt goes beyond where OpenWrt is in quite a few ways.

I was frustrated by Homenet's early belief's (on no data) that lots of things weren't feasible due to code/data footprint; both Dave and I knew better from previous work on embedded hardware.  As example, Dave put a current version of bind 9 into the build (thereby proving that having a full function name service in your home router was completely feasible; that has aided discussions in the working group) since.

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.

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.


Jim





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]