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

[Nikos Mavrogiannopoulos]

On Wed, 2015-03-25 at 18:19 -0400, Robert Edmonds wrote:

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

You could run multiple validating servers on the same hardware if you
like. But it is not up to you to impose this decision to everyone else.
That's up to local policy to decide.

[...]

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

I really cannot understand what point are you trying to make, and it is
irrelevant to the issue anyway. What guarantee do you have that the
AF_LOCAL interface is not forwarded to some other host for verification?
What about the API? How are you sure it is not an API compatible library
which uses RPC to validate the replies? In all the cases the
administrator can degrade, or even disable security if he wants to.
Pretending that using an API or AF_LOCAL is better to protect from that
is a fallacy.

regards,
Nikos