Re: Building consensus over DNSSEC enhancements to glibc.

[Rich Felker <dalias at libc dot org>]

On Mon, Nov 16, 2015 at 01:31:58PM -0500, Simo Sorce wrote:
> On 16/11/15 13:23, Rich Felker wrote:
> >On Mon, Nov 16, 2015 at 01:19:42PM -0500, Simo Sorce wrote:
> >>On 16/11/15 13:17, Rich Felker wrote:
> >>>On Mon, Nov 16, 2015 at 12:18:37PM -0500, Simo Sorce wrote:
> >>>>On 16/11/15 11:16, Rich Felker wrote:
> >>>>>On Mon, Nov 16, 2015 at 06:37:55PM +0900, Paul Wouters wrote:
> >>>>>>On 11/10/2015 03:03 AM, Rich Felker wrote:
> >>>>>>>On Mon, Nov 09, 2015 at 11:57:29AM +0100, Petr Spacek wrote:
> >>>>>>>>One of reasons why 'nameserver 127.0.0.1' only cannot work are systems which
> >>>>>>>>boot from network. Imagine that the system is booting so it does not
> >>>>>>>>necessarily have local resolver running (yet) but the system might need to
> >>>>>>>>mount NFS share with / from somewhere, probably from a NFS server which is
> >>>>>>>>identified by DNS name.
> >>>>>>>
> >>>>>>>That works perfectly well. You simply configure it to use the
> >>>>>>>nameservers from dhcp as the upstream sources for the nameserver
> >>>>>>>running on localhost.
> >>>>>>
> >>>>>>That does not address the problem of the network being able to set AD bits in DNS packets.
> >>>>>>AD bits are _not_ protected by a signature of any kind.
> >>>>>
> >>>>>You don't use or retransmit these AD bits at all. The local nameserver
> >>>>>has to check all signatures itself and generate its own AD bit in the
> >>>>>response.
> >>>>
> >>>>I guess the misunderstanding here is that, unless glibc drops AD
> >>>>bits by default, as opposed to only dropping them when a special
> >>>>option is set, then applications cannot trust if the AD bits were
> >>>>set by a trusted resolver or by a random "internet cafÃ" compromised
> >>>>DNS server that is used as the nameserver option in resolv.conf
> >>>
> >>>Glibc neither "drops" nor "preserves" AD bits because it does not
> >>>produce dns packets as output. It produces struct addrinfo and struct
> >>>hostent, neither of which has such a concept.
> >>
> >>So you are saying that Carlos's proposed `options
> >>dns-strip-dnssec-ad-bit` will do absolutely nothing ?
> >
> >I don't even understand what it means, but presumably it's in the
> >context of adding some extension where the AD bit is reported in the
> >getaddrinfo results. I question whether there is any valid reason to
> >have such an extension in the first place. I have not yet seen a
> >proposed usage case where it's needed that doesn't involve hopelessly
> >insecure configurations.
> 
> We are talking about this stuff exactly because hopelessly insecure
> configurations are the norm, and we want to do something sensible
> about it that can be gradually improved without falling on our faces
> in the process.

I'm not saying that doing this contributes anything to security in the
"hopelessly insecure configurations". I'm saying that there's nothing
meaningful to report to the application in proper configurations, and
that in the "hopelessly insecure configurations" reporting trust info
that can't actually be trusted is irresponsible and harmful.

Rich