On 27.2.2014 06:46, Viktor Dukhovni wrote:
On Thu, Feb 27, 2014 at 12:29:57AM -0500, Paul Wouters wrote:
So likely RedHat should proceed with extensions to resolv.conf to
express the trust status of the nameserver list, and improvements
to libresolv. The default stub-resolver policy can reasonably be
Note that we don't want to hack resolvers in Red Hat's software.
We really want to reach a consensus about this problem so we (Red Hat) can
work upstream with stub-resolver developers to add support for the new
behavior as designed here.
Please do not limit the discussion to glibc/libresolv/ldns/anything else. We
are interested in resolver-behavior in general not in one particular
implementation.
non-trust of all nameservers (typically from DHCP).
But it is so much better for all server installs to just install a
validating resolver, point resolv.conf to localhost, and use the DHCP
obtained DNS servers (or admin configured DNS servers) as forwarders.
Then all applications can trust the AD bit. That's a simply a reality
that's possible today. Even upgrading machines to this is not that hard.
Yes, up-thread, this my ideal future world too.
Sure, this is ideal, it is absolutely clear that (local) validating resolver
is the best option (when possible).
Now we need to discuss 'a temporary solution' for the case where a validating
resolver is not available for whatever reason.
Please let's concentrate on following situation:
- Crypto libraries like GnuTLS/OpenSSL/NSS have DANE support compiled and
enabled by default out-of-the-box.
- GnuTLS/OpenSSL/NSS libraries use AD bit as received from stub-resolver.
- A random application (e.g. Firefox/Thunderbird/offlineimap) use DANE-enabled
crypto library and have no clue about DNSSEC. (That is what we want, right?
Just use it without modifying all crypto-enabled applications in the world!)
- The whole set is running on machine with plain stub-resolver without
validator.
Result => It is completely insecure because attacker can use DANE for
effective man-in-the-middle attack: The crypto library will trust to fake TLSA
records because attacker send fake TLSA record with AD=1.
One opinion is 'use a new shiny API for DNS and do not hack existing resolver
APIs' and the other option is to 'do validation yourself'. I'm afraid that
this do not belong to category 'temporary solution'.
It can take too long to design API, then to develop libraries and then *to
convince application developers to use this new API*.
I definitely agree that old resolver from BIND8 is "not the best" but we have
to count with existing applications. It is easier to push small patches like
- res_init()
+ res_init_trusted()
It is *much much* harder to push patches rewriting code related to DNS to some
completely new library. We want to add DANE support to existing applications
not only to new ones.
The proposed approach with a new initialization call (*for example*
res_init_trusted()) have two (desired) side-effects:
- It prevents an application relaying on AD bit from running on old system
which does not guarantee trustworthiness of the AD bit. Otherwise we would
have to invent some way how to check at run-time that special handling for AD
bit is supported. (Think about cases where application was compiled on newer
system and somebody tries to run it on older system etc.)
- It doesn't affect applications which do not care/do not use new
initialization call.
For example current software like Postfix or OpenSSH client will 'just work'
without any change. AD bit will be handled in special way only if the resolver
library is initialized with the new call.
That's why I'm not really in favour of adding legacy to glibc or
resolv.conf. Especially because there are also so few applications that
actually do anything with AD bits, plus we are still working on API and
The main idea is 'to make DNSSEC easy for application developers - today'.
It doesn't surprise me that very few applications use AD bit because nowadays
it requires adding a new configuration option "resolver is un/trusted" to the
application. It is not easy neither for programmer nor for administrator.
DNSOP documents on how to improve/secure the DNS transport for talking
to remote servers.
I'm sorry, this also sounds like a long-term plan. We are looking for
something workable today. The plan is to push DANE support as much as possible
and as soon as possible - not to wait (potentially long time) for
standardization and adoption of new APIs etc.
But what to do when things are not ideal, perhaps because someone
disagrees with our ideal. How do we let them assert that AD should
be trusted?
One could always trust AD, and leave up to the platform vendor and
system administrator to make it so. Or one could default to not
trust AD unless resolv.conf says so, and the out-of-the-box
"experience" could be made to include a 127.1 nameserver and the
the right new predicate in /etc/resolv.conf, and glue to have DHCP
tweak forwarders (subject to relevant DHCP configuration) rather
than mess with resolv.conf (much better for reasons beyond DNSSEC
IMHO).
Then it is up to adventurous administrators to mess this up. Some
will want to bless "remote" resolvers, that we might not want
to bless by default.
As to the question of whether always trusting AD when the recursive
resolvers are not "secure" is OK? I don't know. Depends what
applications do with that trust.
Please see the example with DANE-enabled crypto library above.
Have a nice day!
--
Petr^2 Spacek
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
