Re: Building consensus over DNSSEC enhancements to glibc.

[Rich Felker <dalias at libc dot org>]

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.

Rich