Re: Building consensus over DNSSEC enhancements to glibc.

[Petr Spacek <pspacek at redhat dot com>]

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.


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.


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

-- 
Petr Spacek  @  Red Hat