Re: Building consensus over DNSSEC enhancements to glibc.

[Petr Spacek <pspacek at redhat dot com>]

On 11.11.2015 16:45, Rich Felker wrote:
> On Wed, Nov 11, 2015 at 01:49:45PM +0100, Petr Spacek wrote:
>> On 10.11.2015 18:49, Rich Felker wrote:
>>> On Tue, Nov 10, 2015 at 11:17:56AM +0100, Petr Spacek wrote:
>>>> On 9.11.2015 19:03, 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. All this requires is changing your dhcp client
>>>>> scripts to store the nameservers somewhere other than resolv.conf and
>>>>> notify the local nameserver to use them. The difference from normal
>>>>> dhcp setups is that it's secure against fake/malicious nameservers. If
>>>>> the dhcp-provided nameservers produce fake records, the signatures
>>>>> won't match (or won't be present) ansd they won't be used. In that
>>>>> case the local nameserver can try to fallback to known upstream
>>>>> sources or doing its own recursion if desired; otherwise all lookups
>>>>> just fail.
>>>>
>>>> This can work in theory but you would have to have whole DNSSEC
>>>> validator/crypto stack in the init ramdisk, which may not be an option.
>>>
>>> That's only the case if you need DNS before the real filesystem comes
>>> up, for instance if you'll be obtaining the root fs from the network.
>>> In that case you already need at least some sort of cryptographic
>>> validation (albeit maybe just a static list of acceptable
>>> cryptographic hashes) in the initrd. Otherwise you have a trivial
>>> arbitrary code execution vulnerability.
>>>
>>>> As Simo said, failing safe is the an important principle in security land so
>>>> saying 'that should not happen' is not good enough.
>>>>
>>>> What would be an acceptable way to implement this in a fail-safe way?
>>>
>>> What specifically is "this"?
>>
>> Let me use TLS analogy to explain what I mean with 'failing-safe' for DNSSEC API:
>>
>> 1. API purpose & configuration
>> - TLS: Imagine that 'the API' is a function call allowing applications to
>> establish TLS connection. The library which provides such API has to have some
>> configuration knobs: One of them is filesystem path where list of trusted CAs
>> is located.
>> - DNSSEC: API is used to obtain DNSSEC-validated data. Configuration knob is
>> in our case list of IP addresses of trusted DNSSEC validators.
>>
>>
>> 2. Imagine that I just installed the library and an application using it to a
>> new system. This system never saw that library/API before so it does not have
>> appropriate configuration.
>> - TLS: List of trusted CAs is not in the default path used by library.
>> - DNSSEC: User just upgraded glibc but did not do any additional configuration.
> 
> This is a systems integration error, making changes in the wrong
> order. As long as it fails safe (everything fails) that's not a
> security risk, but it's still bad. Upgrades should be properly ordered
> or atomic.
> 
>> 3.
>> - TLS: Failing safe in this analogy means that when an application calls the
>> API the certificate validation will fail because there is no list to validate
>> against - so the application will receive a return code saying 'unable to
>> verify cert'.
>> - DNSSEC: In our case application never sees AD bit set to 1.
> 
> My view here is that "fail-safe" means unconditional ServFail in this
> situation.
> 
>> 4.
>> - TLS: Failing open in this analogy means that on systems where the list of
>> trusted CAs is not present the validation will always pass.
>> - DNSSEC: In our case the application sees AD bit set by attacker, which is
>> roughly equivalent to an attacker sending arbitrary cert which gets accepted.
>>
>>
>> Does it explain what I mean by 'failing-safe'?
> 
> It leaves me more confused which properties you're calling
> failing-safe. To me, failing-safe means you never accept
> possibly-forged data. But it's not clear to me whether you're also
> wanting to include "works but reports lack of signatures" as part of
> your definition of fail-safety. I would not want to include that.
> Allowing bypass of cert errors was a mistake for TLS deployment and
> it's a mistake for DNSSEC too.

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

-- 
Petr Spacek  @  Red Hat