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

[Robert Edmonds]

Nikos Mavrogiannopoulos wrote:
> On Wed, 2015-03-25 at 14:00 -0400, Robert Edmonds 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?
> 
> It depends how the network is organized. It can be a server on the
> localhost, a server on a different VM, or container.

How does a server on a different VM count as local, even if running on
the same chassis?  (Also, you do exclude across a physical LAN/WLAN/etc.
from your definition of local, right?  Just making sure.)

> That is system policy applications cannot and should not enforce.

I disagree.  What's the use case for easily allowing, as a configurable
policy, delegating an application's cryptographic validation to a server
that may be off-host?

> > 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.
> 
> That's the same guarantee of you connect to unbound via localhost. It is
> no different than connecting via unix sockets or using the API of
> libunbound.

I agree that non-validating stub resolution via localhost or AF_LOCAL to
a validating server running on the same host is the same guarantee as
calling libunbound -- validation takes place on-host, if not in the same
process, then by a privileged process running on the same host.

But your c-ares pull requests (#20, #21, #22) don't guarantee that
validation takes place on-host (i.e., via localhost/loopback).

> > 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.
> 
> I don't see any difference of AF_LOCAL with the loopback interface.

Nor do I, but there is no guarantee that servers listed in resolv.conf
(or resolv-sec.conf) are on the loopback interface.

-- 
Robert Edmonds
edmonds at debian.org