Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Robert Edmonds]

Hi, Nikos:

Nikos Mavrogiannopoulos wrote:
>  The D-BUS interface is not really necessary because DNS provides
> already this functionality. What we need is a convention for
> applications in the system to discover the local trusted (for dnssec)
> nameservers. 

What do you mean by "local"?  A nameserver listening on localhost, or
only a nameserver on the local network?

> My attempt to use c-ares for dnssec resolving would have the same effect
> as the ones you mention and is much cleaner and straightforward than
> D-BUS. However, it is blocked by the fact that there is no commonly
> acceptable convention for reading the trusted nameservers. My current
> solution was to use /etc/resolv-sec.conf, but it is pretty much
> arbitrary and that's why c-ares upstream blocked it. If Debian would set
> such a convention, I think it would allow software use DNSSEC easier.
> 
> https://github.com/bagder/c-ares/pulls

If I understand this pull request correctly, it only checks that the AD
bit is set in responses; in the language of RFC 4033, that makes this a
"Non-Validating Security-Aware Stub Resolver".

libunbound, OTOH, is a "Validating Stub Resolver" (it can also do full
recursion if no forwarders are configured).  A tool that uses libunbound
can guarantee that the result is cryptographically authentic, to the
limits of the integrity of the local system.

So, I disagree with you if you are saying that trusting the AD bit
without validating from a nameserver on the local network (even if it
has been marked as "trusted" by local policy) has the same effect as
validating on the endpoint (whether it be by a trusted process or by a
nameserver bound to a privileged port, etc.).

Maybe better than a D-BUS service would be DNS transport over an
AF_LOCAL / SOCK_DGRAM socket; that can also guarantee that validation
happens on the local system by a trusted process.

Though, I wonder why danetool / libdane must perform the DNS lookup
itself.  Couldn't it also have an interface for accepting fetched TLSA
records that have already been validated by an external tool?  (I see
that it can fetch certificates from remote servers, too, so I guess it
wants to be an all-in-one tool.)  E.g., unbound-host can securely fetch
TLSA records:

    $ unbound-host -v -f /usr/share/dns/root.key -t TLSA _443._tcp.www.nic.cz
    _443._tcp.www.nic.cz has TLSA record 3 1 1 AA7B93DAAB084536530BD3256E9CEFF4557CB43512640F7AB64487DC9CA14FAB (secure)
    $

Also, unrelated to this discussion, I notice that gnutls hardcodes the
path to the root trust anchor file at compile time:

    AC_ARG_WITH(unbound-root-key-file, AS_HELP_STRING([--with-unbound-root-key-file],
                                     [specify the unbound root key file]),
                unbound_root_key_file="$withval",
    if test "$have_win" = yes; then
        unbound_root_key_file="C:\\Program Files\\Unbound\\root.key"
    else
        if test -f /var/lib/unbound/root.key;then
            unbound_root_key_file="/var/lib/unbound/root.key"
        else
            unbound_root_key_file="/etc/unbound/root.key"
        fi
    fi
    )

This is not right; a buildd environment won't have a running unbound
daemon and thus won't have a /var/lib/unbound/root.key file, and
/etc/unbound/root.key won't normally exist on a Debian system.  (There
is a package in Debian that ships the root trust anchor, though:
dns-root-data.)

-- 
Robert Edmonds
edmonds at debian.org