[cc'ed to a more approriate IETF wg]
On Sep 10, 2013, at 11:55 AM, Jim Gettys <jg(_at_)freedesktop(_dot_)org> wrote:
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.
See: https://plus.google.com/117091380454742934025/posts/XeApV5DKwAj
Jim
My colleagues and I worked on OpenWrt routers to get Unbound to work there,
what you need to do is to start DNS up in non-validating mode
wait for NTP to fix time, then check if the link allows DNSSEC answers through,
at which point you can enable DNSSEC validation.
see:
https://www.dnssec-deployment.org/index.php/2012/03/a-validating-recursive-resolver-on-a-70-home-router/
We also discovered that some cheap devices like this will do NTP at startup and
never again that combined with long up-time and bad clocks
caused the Validators to start rejecting signatures due to the time on the
signatures.
The big issue is that validator implementors assume that it runs on good
hardware with good links, thus it is safe to enable DNSSEC out of the gate.
We need either have resolvers come up in recursive mode and tool like
dnsec-trigger or our scripts change the behavior to validator after that has
been
deemed safe, or build the checking into the validators.
The same can be said of devices that have been installed from media or have
been turned off for a long time (say month or more), in these cases
starting up in validating mode only only turns the device into a brick.
Olafur