Re: [dane] An AD bit discussion

[Petr Spacek <[e-mail]>]

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