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

[Nikos Mavrogiannopoulos]

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. That is system
policy applications cannot and should not enforce.

> 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.

> 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.

regards,
Nikos