Re: Building consensus over DNSSEC enhancements to glibc.

[Rich Felker <dalias at libc dot org>]

On Mon, Nov 16, 2015 at 12:16:35PM +0100, Petr Spacek wrote:
> On 11.11.2015 18:07, Rich Felker wrote:
> > On Wed, Nov 11, 2015 at 05:41:22PM +0100, Petr Spacek wrote:
> >> Ah, I see. This example might be confusing because with TLS you have only two
> >> states: Fully validated (secure?) or not-validated (insecure?). On the other
> >> hand, in DNS we have four security states, not only two (see RFC 4033 section
> >> 5 and RFC 4035 section 4.3).
> >>
> >> When reading this, consider glibc to be "Non-Validating Security-Aware Stub
> >> Resolver" (RFC 4033 section 2).
> >>
> >>
> >> Now back to the DNSSEC security states:
> >> "servfail" should be returned for security state "bogus", but "bogus" state
> >> can be returned by validator which detects this state. This is not our case
> >> because we do not have any validator yet (because the system is configured yet).
> >>
> >> In fact, because the system was not configured to do validation yet, we are
> >> talking about handling of "Indeterminate" state which according RFC 4033
> >> section 5 is handled in the same way as state "Insecure", i.e. the AD bit
> >> should be 0.
> >>
> >> I'm not making this up :-)
> > 
> > I accept that you're not making this up. What I question is whether
> > the people who did make it up are repeating the same mistakes that
> > browsers made with TLS (making it easy to accept forged certs).
> > 
> > My view is that there are two types of system setups:
> > 
> > 1. Using DNSSEC: only localhost should be used for queries, and when
> >    not available, all queries should fail with the equivalent of
> >    ServFail.
> > 
> > 2. Not using DNSSEC: same situation as now.
> 
> 'Not using DNSSEC: same situation as now' goes directly against the gold DNS
> standard. Please see original (i.e. pre-DNSSEC) RFC 1035:
> http://tools.ietf.org/html/rfc1035#page-26 section 4.1.1 Header section format.
> 
> It clearly states what to do with bits 9, 10 (AD), and 11 in message header:
> "Reserved for future use. Must be zero in all queries and responses." So, if
> you decide not to use/ignore DNSSEC please do it in a standard-compilant and
> at the same time secure way: Zero out these bits unconditionally.

In such a setup, no DNS packets are being generated at all. You're
using someone else's nameserver that could forge whatever it wants (or
whose payload could be forged by MITM on the network).

> > I believe your position, and the position of the people who designed
> > this stuff, is that there should be a third option:
> > 
> > 3. Might have DNSSEC: query result needs to report to the application
> >    whether the result has a valid signature or not. Known forgeries
> >    should probably be dropped as ServFail still, but unsigned answers
> >    could be reported.
> > 
> > IMO this third setup creates a lot more room for misconfiguration and
> > essentially replicates the problems you always have with opportunistic
> > encryption.
> 
> This is probably a misunderstanding. It has nothing to do with opportunistic
> encryption, it is about incremental deployment.

But it has exactly the same inherent risks as opportunistic crypto.

> This third option is a 'must have' for incremental deployment. There are no
> flag days on the big Internet. Nobody can 'turn on DNSSEC' on all DNSSEC
> domains in the global DNS tree.

As I understand it, all domains in the global DNS tree either require
signatures or have a way to obtain a signed chain of records saying
that they do not use DNSSEC. Either of these is sufficient to treat a
result as valid (i.e. not ServFail it).

If this is incorrect, could you explain how/why?

Rich