Re: Looking for dnssec-triggerd alpha testers!



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


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