Update to DNSSEC design document.

[Rich Felker]

On Thu, May 21, 2020 at 09:33:21AM +0200, Petr Špaček wrote:
> On 20. 05. 20 19:36, Rich Felker wrote:
> > On Wed, Jan 27, 2016 at 12:30:28PM -0500, Carlos O'Donell wrote:
> >> This is not for 2.23, but I wanted to mention this update:
> >>
> >> https://sourceware.org/glibc/wiki/DNSSEC
> >>
> >> I have spent significant amounts of time with the Fedora
> >> and RHEL distribution teams talking about potential solutions.
> >>
> >> The most relevant change is that in order to support truly
> >> fail-safe configurations we're going to suggest the solution
> >> clean the AD-bit in responses by default, with the distribution
> >> being in charge to setup a validating resolver configuration
> >> (various distribution-level choices including a fixed nscd) after
> >> which an option is set in /etc/resolv.conf. From that point on
> >> the AD-bit is forwarded to applications. This makes creating a
> >> fail-safe configuration very flexible and distributions can
> >> choose exactly how they accomplish ensuring there is trust for
> >> the entries in /etc/resolv.conf.
> >>
> >> I believe I have a conversation thread with Zack Weinberg that
> >> I still have to finish.
> > 
> > I think the policy around AD bit needs serious reconsideration. The
> > main/only use of AD bit in applications makes clearing it fail-open
> > rather than fail-safe. In particular, for DANE, which is really the
> > only situation where you need to distinguish insecure vs authenticated
> > zone rather than just trusting the nameserver not to give you forged
> > data for authenticated zones, AD bit set means "honor DANE records for
> > this domain" and AD bit clear means "ignore DANE records for this
> > domain". By stripping AD, glibc is making policy more permissive, and
> > making applications silently fail to honor an essential security
> > property.
> 
> I do not agree with this view.
> 
> In my optinion:
> - AD bit stripping ensures the application can trust the answer
> (which is exactly tu purpose of AD bit).

With or without AD stripping, the application can trust the answer
precisely to the extent that the configured nameserver is trusted. AD
stripping has no bearing on that whatsoever.

> - Without AD bit stripping the application is potentially exposed to
> any attacker who can spoof DNS answers.

This is false, or at least misleading by not specifying *at what
point* in the flow the attacker can spoof.

If they can spoof between the stub resolver (glibc) and the configured
nameserver, the application is exposed to forged replies *regardless*
of AD stripping.

If they can only spoof between the configured nameserver and upstream
internet, then they can forge only insecure zones (insecure means
provably-insecure).

In your examples, it looks like you're assuming they can spoof between
stub and configured nameserver:

> E-mail example *without* AD bit stripping:
> 1. Attacker spoofs IP address of target e-mail server. Now e-mail is
> being delivered to attacker's IP address.
> 2. Attacker spoofs TLSA answer for target domain with AD=1. Now
> client e-mail software was fooled to think that attacker-provided
> cert in the fake TLSA record is valid for target domain.

With AD stripping it's even easier: TLSA will not be checked at all.
The attacker doesn't even need to spoof it.

Your misconception here is that lack of AD bit will prevent delivery.
That couldn't be further from the truth. Instead, lack of AD bit tells
the client "the operator of this domain does not care; you can happily
deliver in cleartest".

> In other words not stripping AD bit means that attacker can spoof
> everything making it undetectable in client application.

No, stripping AD means that.

> I really cannot see how it is better than stripping by default,
> which allows the application to detect that something in DNSSEC
> validation chain is not configured properly. (Possibly misconfigured
> resolv.conf.)

Lack of AD bit does not mean that something in the DNSSEC validation
chain was misconfigured. It means that the queried zone was insecure
(not protected by DNSSEC).

> What is you counterproposal?

Stop stripping AD. It's strictly harmful. There is no case where it
improves security. Document that, to prevent forgery, you need to
trust the configured nameserver and the route to it and that the
recommended usage is to run a DNSSEC-validating nameserver on
localhost.

Rich