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

[Robert Edmonds]

Hi,

Cyril Brulebois wrote:
> James Cloos <cloos at jhcloos.com> (2013-12-29):
> > >>>>> "AM" == Andreas Metzler <ametzler at bebt.de> writes:
> > 
> > AM> libdane requires and links against libunbound. libunbound OTOH
> > AM> is linked against OpenSSL's libssl on Debian[1].
> > 
> > A possible way forward is to configure unbound --with-nss, which
> > should provide license compatibility for all libunbound users.
> 
> (Background: This issue has just been pointed out to me after a GNUnet
> conference. At least one developer there is interested in seeing a fix
> reach the archive.)
> 
>  1. Not having looked too much at unbound yet, it seems to indeed
>     support NSS instead of OpenSSL, so one might think about switching
>     to it to get rid of (possible) OpenSSL license incompatibilities.

With my unbound maintainer hat on, I would only want to switch Unbound
from OpenSSL to NSS if this were considered a production-ready
configuration supported by upstream.  (I haven't researched whether this
is the case, but I suspect the NSS option has gotten substantially less
testing than the OpenSSL default.)

>  2. A softer way might be to build an NSS variant of the unbound library
>     alongside with the OpenSSL (current/default) one, so that packages
>     like GnuTLS can pull it instead, and deliver DANE support.

Hm, possibly.

FWIW, IIRC Unbound needs OpenSSL for three different reasons:

 * libssl: In the unbound daemon, TLS is used to protect the
   communication between unbound-control and the unbound server.
   However, this is only really useful for unbound-control running on a
   remote host.  (Recent versions of unbound support an AF_LOCAL socket
   for the control socket, though I can't remember if it is still
   TLS-protected for some reason or not.)

 * libssl: In the unbound daemon and libunbound, too (I think), there is
   support for an "ssl-upstream" option that forwards queries to a
   remote Unbound server running with the "ssl-port" option.  This is an
   Unbound-specific transport option (I don't think any other DNS
   servers support it), not part of the "real" DNS protocol.

 * libcrypto: For doing the actual DNSSEC validation crypto operations.

If the "ssl-upstream" feature were somehow hacked out of libunbound (but
not necessarily the Unbound server itself), would it help?  Then there
would only be a libcrypto dependency, and maybe that is more manageable
to replace?

See also:

    https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=594

>  3. Yet another way might be to teach unbound to support GnuTLS in
>     addition to OpenSSL and NSS, so that one can build a GnuTLS variant
>     instead of an NSS one.

By 'unbound', do you mean the Unbound server, or libunbound?

And what do you make of this comment on upstream bug #594:

    The other option would be to add support GnuTLS but then you have a
    circular dependency preventing libgnutls-dane from ever being merged
    into libgnutls.

> Solution 1 seems harsh and could possibly break rdepends; solution 2
> seems safer and only a (small?) matter of packaging; solution 3 might
> involve some bits of coding, and might cause tests entanglements in
> configure.ac.
> 
> Thoughts? Should I look into patching unbound to support solution 2?

There is also a solution 4:

 4. Design and implement a D-Bus interface for securely retrieving
    DNSSEC-validated records that have been validated *on the system*.
    Patch daemons (Unbound, BIND, et al) to answer to this interface.
    Patch clients (libdane, et al) to request records using this
    interface.

This is sort of analogous to the security you would get in having a
plain validating DNS server listening on localhost and a "nameserver
127.0.0.1" line (and no others) in /etc/resolv.conf and requiring the
"AD" bit in responses, but the big advantage would be that the security
guarantee from doing DNSSEC validation directly on the endpoint is
guaranteed by the definition of the interface, and not from the
happenstance of local configuration.

This would:

 * Avoid licensing issues.
 
 * Avoid extra TLS/crypto related library dependencies in clients.

 * Allow other validators that are not written in the form of a library
   (e.g., BIND, PowerDNS) to be used with clients that need
   DNSSEC-secured answers.  And for validators that do have a library
   API, do you really want to have each client have its own #ifdef mess
   to support multiple APIs?

 * Allow system-wide, not just process-wide caching.  (Even if your
   direct-libunbound client is pointed at a resolver on 127.0.0.1 that
   has the answers in cache, it still may need to do many send/recv
   system calls to obtain each needed record, because DNS can only
   return one answer at a time per query/response.)

 * Insulate the client from needing to know how to configure the
   DNSSEC-lookup library.  (E.g., remote DNS servers, trust anchors,
   etc.)

That is substantially more work, though.

-- 
Robert Edmonds
edmonds at debian.org