Re: Building consensus over DNSSEC enhancements to glibc.

[Petr Spacek <pspacek at redhat dot com>]

On 16.11.2015 17:23, Rich Felker wrote:
> 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).

Yes, that is correct, but keep in mind that this applies to receiving messages
as well. All pre-DNSSEC responses *must* contain AD bit set to zero, so if we
are pretending that DNSSEC does not exist we have to zero out the AD bit, too.
Not doing so would be a security nightmare.

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

Technically this is correct if DNSSEC validator configuration contains trust
anchor for root zone. It would not be true for other configurations.

Anyway, this is exactly the case where unsigned answers are returned and must
be accepted, which effectively means that parts of DNS tree can be attacked
(because they did not bother do deploy DNSSEC) - this is my understanding of
your variant (3) above.

-- 
Petr Spacek  @  Red Hat