Looking for dnssec-triggerd alpha testers!

[Paul Wouters]

On Wed, 21 Sep 2011, Adam Tkac wrote:

> this is a great idea and work. We talked (inside Red Hat) about similar
> approach how to secure the clients but this proposal is better, ready
> for use, and I like it.

Great. Please test and give us feedback :)

> The only one question for discussion is if we should "disable DNSSEC
> when it is proven untrusted". Previously, I tended to use similar
> approach but after discussion with security guys I think we shouldn't go
> this way.
>
> The main problem is how to differ between misconfigured ISP's
> proxy/server which strips DNSSEC data (good example is bind 9.3, still
> widely used, and it's default "dnssec-enable no;" setting) and MITM
> attack which strips DNSSEC data. Due this I think we should always
> enforce DNSSEC, user should explicitly modify unbound or riggerd
> configuration to disable DNSSEC. Otherwise we can end with same
> situation as with X.509 certs on the Internet - when cert is bad,
> everyone automatically accept it and there is no security benefit.

Currently, a big warning comes that tells you you can either continue
from your current cache (with causes new lookups to fail) or to go
insecure. We're trying to gain more hotspot experiences to see how
well this works. If we can do auth dns ourselves in the majority of
causes, we might be better of then we think. Networks with bind 9.3
tend to not firewall port 53, so moving in such a network should be
mostly transparent.

> Another argument for enforcing DNSSEC is that in future (well, I believe
> :) ) DNS will be used as storage for X.509 certs, SSHFP records and
> other stuff. If we adopt "leisure" approach (automatic disabling of
> DNSSEC or ability to "click" somewhere on the applet to disable DNSSEC)
> then we can end in the same situation as we are currently with X.509
> certs.

There is a difference still. Applications can still see the difference
between the localhost resolver returning the AD bit or not. So going
insecure will render the sshfp/dane records "uselesss", they will not
be trusted. Note also that with "dnssec chains" via TLS, either as a
TLS extension or as part of a certificate blob, the non-attack case
will be able to work in the browser even if fetching DNS via the network
is broken/misconfigured.

> Everyone will simply click on "disable DNSSEC" button or, when
> MITM attack will be in progress, DNSSEC will be automatically disabled.
> This will degrade DNSSEC benefits.
>
> When we enforce DNSSEC there will be definitely some users which will
> end with "broken" DNS but this is a great opportunity how to really
> secure end nodes.

One of the reasons we are trying this, is to gain experience in how bad
DNS at the endnode really is.

So I agree, we're not yet ready to inflict it on mortals, just on developers :)

Paul