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.
--
Petr Spacek
Software Engineer
Red Hat
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
