Re: Building consensus over DNSSEC enhancements to glibc.

[Petr Spacek <pspacek at redhat dot com>]

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.


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

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 a consequence, there must be a way to deploy DNSSEC incrementally.
Effectively this means that there are parts of DNS tree which are signed and
parts which are not signed, and this must not break clients. This is why
option 3 is inevitable.

Petr Spacek @ Red Hat

>> Search in RFC 4033 for "Indeterminate" and you will get two hits
>> - ... "This is the default operation mode."
>> - "The current signaling mechanism does not distinguish between indeterminate
>> and insecure states."
>>
>> Does it explain why AD bit should be cleared instead of returning servfail in
>> cases where validator is not available?
> 
> Yes, but I think it's bad security policy and should not be
> implemented. It's also not a situation you can get into if you have a
> local validator. The validator is always available, and can always
> determine whether an answer is valid or forged.