Re: [DNSOP] DNSSEC AD bit handling in stub-resolvers

[Petr Spacek <[e-mail]>]

Greetings,

Paul Wouters and me have accidentally open threads about the same topic on 
this list and also on dane-list. I guess that this discussion fits better to 
dane-list so please discuss there.

I'm sorry for the noise.

Petr Spacek

On 26.2.2014 16:44, Petr Spacek wrote:
> Greetings,
>
> I'm Petr Spacek from Red Hat's Identity Management group. We plan to extend
> support for DNSSEC (including DANE and others) in open-source software and we
> would like to discuss the right implementation approach with you.
>
> 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. 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.
>
> 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() or
> for glibc res_init_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 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.
>
> We would like to hear your opinions and recommendations for this area.
>
> Thank you for your time.