Re: Building consensus over DNSSEC enhancements to glibc.

[Rich Felker <dalias at libc dot org>]

On Mon, Nov 16, 2015 at 08:07:20PM +0100, Petr Spacek wrote:
> On 16.11.2015 19:21, Rich Felker wrote:
> > On Mon, Nov 16, 2015 at 07:13:04PM +0100, Petr Spacek wrote:
> >>>> 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 I understand it, all domains in the global DNS tree either require
> >>> signatures or have a way to obtain a signed chain of records saying
> >>> that they do not use DNSSEC. Either of these is sufficient to treat a
> >>> result as valid (i.e. not ServFail it).
> >>>
> >>> If this is incorrect, could you explain how/why?
> >>
> >> Technically this is correct if DNSSEC validator configuration contains trust
> >> anchor for root zone. It would not be true for other configurations.
> > 
> > If you don't have that, you have a broken installation. This is no
> > different from having a glibc that has been actively patched to break
> > any other security invariant.
> 
> No, it is not an invariant. DNSSEC RFCs do not hardcode signed root, and
> deployments isolated from public Internet may very well want to use trust
> anchor only for a particular DNS sub-tree (unless they deploy their own signed
> root, too).

Aside from questioning whether people are actually making such
deployments or whether this is purely theoretical, I don't see how it
matters. The right way to do such a setup is to have a proper trust
anchor for the root and have it require signatures only for the
particular subtrees you want to use DNSSEC on.

In reality, it seems if you're doing such a thing you should still use
actual domains you own in the global namespace. But I don't think
making it work depends on doing that.

> >> Anyway, this is exactly the case where unsigned answers are returned and must
> >> be accepted, which effectively means that parts of DNS tree can be attacked
> >> (because they did not bother do deploy DNSSEC) - this is my understanding of
> >> your variant (3) above.
> > 
> > If an application is expecting results for part of the tree to be
> > signed (because the DNSSEC infrastructure for it is in place), then as
> > long as the local nameserver validates DNSSEC, you can never get an
> > unsigned or forged result for that part of the tree. So I don't see
> > any use in application-level checking of whether the result was
> > signed. If it wasn't signed the application would never have gotten
> > it.
> 
> Hmm, I do not understand this. How could the *application* know if the target
> domain is DNSSEC-signed or not?

I see two cases here (assuming trusted local nameserver):

- A domain specific to the application. In this case, it knows the
  records are supposed to be signed and that, with a properly
  configured DNSSEC client-side setup, it will never see forged
  records for the domain because the trusted local nameserver will not
  accept them.

- A domain the application encounters as input of some sort. In this
  case, it has no a priori knowledge whether to expect signatures. But
  it knows that it will never see forged records for a domain that is
  using DNSSEC. Domains that have opted not to use DNSSEC may of
  course be subject to forgery.

> I will describe one real example:

Thanks! This is what I've been waiting for.

> Imagine a mail server which is going to send
> e-mail for domain redhat.com. Does the mail server need to know if the domain
> is signed or not? No, that would go against increment deployment property.

Indeed, it can't know for a random destination domain whether to
expect it to be signed.

> So the mail server will simply query domain name _25._tcp.redhat.com for TLSA
> record (basically hash of TLS certificate associated with given domain name,
> see RFC 6698) and see what comes back.
> 
> There are 5 possible outcomes if the domain lies under a trust anchor:
> 1) redhat.com is not signed and TLSA record is not received by the client.
> DNSSEC validation will pass with result "insecure" and the mail server has
> trust the network that nobody is attacking the SMTP connection right now.

Agreed.

> 2) redhat.com is not signed and TLSA record is injected by attacker along with
> AD bit = 1:
> DNSSEC validation will pass with result "insecure". The application *has to*
> see AD bit = 0 and act in the same way as in (1). I.e. AD bit indicates that
> the domain is not signed, so application knows that TLSA records from this
> domain cannot be trusted. Clearing AD bit is *absolutely crucial*.

This is the responsibility of the trusted nameserver running on
localhost. It can never send a reply with the AD bit set unless it has
a full signature chain. The attacker's setting of the AD bit is
utterly irrelevant here because there would be no cause for the local
nameserver to use it. It has to do all signature verification itself.
It cannot just be a forwarder; that's useless.

> 3) redhat.com is signed and TLSA record is not present in the domain:
> DNSSEC validation will pass with result "secure" and application will see AD
> bit = 1, but there are no data to use in application.

OK.

> 4) redhat.com is signed, TLSA record is present in the domain, and received by
> the client:
> DNSSEC validation will pass with result "secure" and application will see AD
> bit = 1. This means that hash of certificate from TLSA record can be compared
> with certificate received from STARTTLS and result of this comparison can be
> trusted, i.e. cert declared in TLSA record can be accepted. No MitM attack is
> feasible.

OK.

> 5) redhat.com is signed and forged TLSA record is sent by attacker along with
> AD bit = 1
> DNSSEC validation will fail with result "bogus" and servfail should be
> returned, because clearly there is something bad happening. Application will
> not see any data.

Agreed.

> And now imagine a system which does not have validator installed or running
> for some reason. Attacker can still play the same tricks as in cases (2) and
> (5). Given the fact that validator is not present, we must treat the data as
> if result of DNSSEC validation was "indeterminate", i.e. clear AD flag. This
> prevents applications from accepting forged data which has to be
> cryptographicaly secure.

Agreed.

> Please note that necessary level of trust is different for different DNS
> record types. For A/AAAA records it is widely accepted that results may be
> forget and applications are counting with that. For other purposes like TLS
> certificate validation it is necessary to have full confidence in the data, so
> validation results has to be properly communicated to the application. The
> list of "must be secure" record types is changing over time, so it is not
> feasible to hardcode list to resolver libraries.

I think the confusion that's had us talking past each other is that my
model was just A/AAAA/CNAME/PTR records, which are the only things the
standard libc APIs give applications easy access to. For these, IMO,
there's little meaning in exposing the AD bit to the application. On a
secure client setup, you know just by getting a reply that the record
is either signed or under a domain that doesn't use DNSSEC. And on an
insecure setup you just have to assume any result could be forged
(same as the pre-DNSSEC world).

Anyway, what I'm not clear on is how you would want to expose the AD
bit to applications wanting to do TLSA lookups, since there's not even
an application-friendly API for this. There's just res_send. So is
your proposal that res_send should patch up the result payload to
remove the AD bit unless the nameserver is configured as trusted? Or
do you want new APIs for other record types, or some extension to
getaddrinfo for them?

Rich