Re: [dane] An AD bit discussion

[Petr Spacek <[e-mail]>]

Greetings,

On 26.2.2014 15:12, Paul Wouters wrote:
> I've been part of a very long and heated discussion about the trust of
> the AD bit. I would like to hear from people here what they think.
>
> I'm currently aware of two (non-dns utilities) applications that make
> security decisions based on "blindly" trusting the AD bit: ssh with
> VerifyHostKeyDNS=yes|ask and Postfix.
>
> libreswan and strongswan are examples of applications that use libunbound
> for in-application DNSSEC validation to avoid needing to trust
> /etc/resolv.conf DNS servers for the AD bit.
>
> First, let me list 4 items everyone seems to agree on:
>
> 1 Applications can either do dnssec validation themselves, or trust the
>    AD bit.
>
> 2 It is undesirable that each application has its own DNSSEC validation
>    code, trust anchors and DNS cache.
>
> 3 It is undesirable that applications blindly trust the AD bit when
>    resolv.conf points to another host as the AD bit could have been modified
>    on the network.
>
> 4 In the ideal world tomorrow, each host has its own automatically
>    configured, perfectly working validing DNS server and resolv.conf can
>    be ignored or is always hardcoded with nameserver 127.0.0.1
>
> Now for my question. Until we reach 4), what should we do with the AD
> bit in getaddrinfo() ?
>
> A) strip the AD bit in struct addrinfo for "untrusted nameservers". A new
>     configuration mechanism will allow white-listing nameservers and 127.0.0.1
>     will always be on the whitelist.
>
> B) do nothing
>
> C) Something else, please specify

Paul and me have accidentally open threads about the same topic on this list 
and also on dnsop-list. I guess that this discussion fits better here so I 
will post our reasoning.

Please note that we would like to discuss the right implementation approach 
with you and not to push described proposal.

I work in Red Hat's Identity Management group and my opinions can differ from 
Paul's, don't be surprised. (I.e. "we" in following text doesn't necessarily 
include Paul :-)


We can see two very basic approaches:
A) Do DNSSEC response validation in each application.
B) Let recursive resolver do the validation and use AD bit in the application.

We consider the first approach (i.e. each application doing response 
validation) too heavy-weight and hard to administer for various reasons:
- Response validation is sensitive operation and application programmers 
should not do it themselves.
- A variant where every application calls validation library is still not 
optimal. Experience with crypto libraries shows that there are many 
opportunities to use a library
incorrectly (in a way which works but is not secure).
- This approach has potential to create administrative nightmare if each 
application decides to maintain own set of trust anchors etc. We can see 
results of such approach in
  PKI world ...


We believe that better approach is to centralize validation in local 
system-wide recursive resolver and use AD bit for signaling that data are 
trustworthy to applications. A
n application should use stub-resolver to talk to local recursive resolver and 
use received AD bit to decide e.g. if it is possible to trust TLSA records or not.

Unfortunately, there are use cases where neither a locally running validating 
resolver nor a trusted path to a remote resolver are available and deployment 
of such is unacceptable.

It seems that existing stub-resolvers unconditionally trust recursive 
resolvers and just forward the AD bit back and forth. This behavior is okay 
only if no application relays on the AD bit. In other words, supporting DANE 
with current stub-resolvers practically requires to add a configuration option 
'recursive resolver is un/trusted' to each and every DANE-enabled application 
and library. (This is exactly what OpenSSH client does. An additional problem 
is that this value has to be maintained as network configuration changes over 
time.)


We would like to make DNSSEC implementation in applications as simple and 
secure as possible. That is a reason why we are looking for a solution for a 
case where AD bit can't be trusted because validating resolver is not 
available for whatever reason. It would allow applications to use AD bit 
without explicit configuration per-application if we solve this case somehow.

Is there any 'standard' way to handle described situation?


We have the following proposal (some people say it is controversial):
- Extend stub-resolvers with a new call for resolver initialization: In case 
of ldns it would be something like: ldns_resolver_new_frm_file_trusted().
- The new call will initialize library as usual + read some system-wide 
configuration (it can be whatever, imagine for example a new file 
/etc/resolv.trusted).
- Client applications will use the same API (except the initialization) to do 
DNS queries.
- When a DNS answer is received from network the stub-resolver will consult 
configuration read from /etc/resolv.trusted:
-- If the particular recursive resolver is listed as trusted - pass AD bit to 
the application.
-- *Otherwise: Clear AD bit and pass the answer with AD=0 to the application.*

This allows an administrator to configure system-wide policy. In case with 
locally running validating resolver or e.g. IPSec tunnel to trusted resolver 
admin can declare it as trusted and nothing changes. However, this mechanism 
allows the system to be safe even in configurations *without* validating 
resolver. No explicit configuration in application is need, just one 
system-wide setting.

It could seem like a minor improvement or a hack, but it allows applications 
to trust the AD bit unconditionally and as a result it significantly 
simplifies DNSSEC implementation and configuration on client machines. We hope 
that this simple approach will allow us to implement and deploy DANE and 
similar technologies widely.

This proposal can be seen as temporary solution before secure transport 
mechanisms like IPSec or CGA-TSIG are widelly available and used. The main 
advantage is that it is easy to implement and it doesn't require any new 
technology so we can use it in applications today.

We would like to hear your opinions and recommendations for this area.

Thank you for your time.

-- 
Petr Spacek @ Red Hat