Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[Olafur Gudmundsson]

[cc'ed to a more approriate IETF wg] 
On Sep 10, 2013, at 11:55 AM, Jim Gettys  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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[Dickson, Brian]

Have you looked at integrating NTP code (and an internal "clock") into the 
Unbound running on the OpenWrt routers?
(If you want something done right, sometimes you have to do it yourself, and 
all that.)

Even if the clock on this hardware is not all that great, is there any 
functionality which can give reasonably reliable status?
Things like, "How many seconds have elapsed since I last asked?", and basically 
run on a combination of occasional NTP plus kind of a temporal "inertial 
guidance", modulo accumulated error?

Good enough for DNSSEC?

Brian

From: Olafur Gudmundsson mailto:o...@ogud.com>>
Date: Tuesday, September 10, 2013 5:59 PM
To: Jim Gettys mailto:j...@freedesktop.org>>
Cc: "dnsop@ietf.org WG" 
mailto:dnsop@ietf.org>>, "i...@ietf.org 
TF" mailto:i...@ietf.org>>
Subject: Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[cc'ed to a more approriate IETF wg]
On Sep 10, 2013, at 11:55 AM, Jim Gettys 
mailto:j...@freedesktop.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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[Masataka Ohta]

Olafur Gudmundsson wrote:

>> 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 :-(.

It is one reason why DNSSEC does not worth deploying

> 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.

That's not secure, especially when some (root, TLD, etc.) expired
zone key is/was compromised.

Masataka Ohta

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[Evan Hunt]

On Tue, Sep 10, 2013 at 05:59:52PM -0400, Olafur Gudmundsson wrote:
> 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. 

That's roughly what we did with BIND on OpenWrt/CeroWrt as well.  We
also discussed hacking NTP to set the CD bit on its initial DNS queries,
but I don't think any of the code made it upstream.

My real recommendation would be to run an NTP pool in an anycast cloud of
well-known v4 and v6 addresses guaranteed to be reliable over a period of
years. NTP could then fall back to those addresses if unable to look up the
server it was configured to use.  DNS relies on a well-known set of root
server addresses for bootstrapping; I don't see why NTP shouldn't do the
same.

(Actually... the root nameservers could *almost* provide a workable time
tick for bootstrapping purposes right now: the SOA record for the root
zone encodes today's date in the serial number.  So you do the SOA lookup,
set your system clock, attempt validation; on failure, set the clock an
hour forward and try again; on success, use NTP to fine-tune. Klugey! :) )

--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[Brian E Carpenter]

On 11/09/2013 09:59, Olafur Gudmundsson wrote:
...
> 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.

Hopefully you also flush the DNS cache as soon as NTP runs. Even so,
paranoia suggests that a dodgy IP address might still be cached in
some app.

Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[Joe Abley]

On 2013-09-10, at 17:59, Olafur Gudmundsson  wrote:

> [cc'ed to a more approriate IETF wg] 

... and I'll gratuitously mention draft-jabley-dnsop-validator-bootstrap here 
too, since it addresses exactly this topic.


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop