Re: [dane] An AD bit discussion

[Viktor Dukhovni <[e-mail]>]

On Wed, Feb 26, 2014 at 05:27:43PM +0100, Petr Spacek wrote:

> 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. An 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.

Please adopt the more modern BSD-style res_ninit(), ... libresolv
interface which improves thread-safety of the stub resolver, and
allows clients to set or query the server list via res_setservers()
and res_getservers().  Extend that API to include a res_ninit_ex()
(or similar) that can specify an alternative resolv.conf file (in
coordination with other implementations if possible).

Some applications will want to explicitly ensure that the trusted
recursive resolver is local.  Others, for better or worse, may
prefer to trust the administrator's judgement about which recursive
resolvers are secure.  See this and related posts in thread by the
same author:

    http://archives.neohapsis.com/archives/postfix/2014-02/0499.html

Applications, that place trust in the AD bit (choose to not implement
their own validation) should be able to decide whether they also
trust everything in /etc/resolv.conf, or whether they'd rather be
sure.

Paul Hoffman's new DNS API may also be something to consider.  I
am hoping Paul or someone else intimately familiar with it can
chime in about that.

> 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?

No.  But you could extend /etc/resolv.conf to support a verb that
marks the AD bit authoritative.  If the file is maintained by the
administrator and uses the new verb, the AD bit is passed on,
otherwise (as e.g. with /etc/resolv.conf populated by DHCP) it is
ignored.  This could be useful for applications that don't want to
employ res_[sg]etserver().

> 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.*

I think this is unwise, forcing all applications that want validated
results to make new platform-specific calls is unwise.  Instead
extend the /etc/resolv.conf syntax:

	nameserver 127.0.0.1
	ad_trusted yes

the default can be "ad_trusted no".  Applications that want to
control the server list and specify a corresponding value of
"ad_trusted" can employ a custom resolv.conf file or call
res_setservers(), which would turn on the AD bit (the application
knows which servers it asked for, and can decide whether to believe
the AD bit).

> This proposal can be seen as temporary solution before secure transport
> mechanisms like IPSec or CGA-TSIG are widely 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.

I don't expect wide adoption of IPSec or TSIG any time soon if ever.

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

Whatever you do, don't force applications to make new calls to
avoid having the AD bit clobbered by the stub resolver.  It must
be possible to configure the system so that the AD is usable with
no changes to applications using the resolver API.

Thus the suggestion to move the signal out of the application and
into /etc/resolv.conf.

-- 
	Viktor.