Re: Building consensus over DNSSEC enhancements to glibc.

[Petr Spacek <pspacek at redhat dot com>]

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).

>> 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 will describe one real example: 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.

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.

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*.

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.

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.

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.


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.


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.

For this reason security status for particular DNS response must be
communicated to applications which can do security decision based on that. And
that this the reason why relaying forged AD bits to applications will cause
catastrophe sooner or later.

-- 
Petr Spacek  @  Red Hat