Re: Building consensus over DNSSEC enhancements to glibc.

[Zack Weinberg <zackw at panix dot com>]

On 11/16/2015 02:07 PM, Petr Spacek wrote:
>>>
>>> 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).

I would argue that such deployments MUST deploy a signed root if they
want to do DNSSEC at all.  If the root isn't signed, then the root
nameserver can substitute unsigned subtrees for signed ones and clients
have no way of telling that this has happened.

> 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:
[...]

I basically agree with your analysis of these cases, except that I don't
trust client applications to process the AD bit correctly.  So, in cases
(1) and (2), where you say report AD=0, I would say "report SERVFAIL and
no records".  (If I remember correctly, the TLSA RFC specifies that TLSA
records MUST be ignored if received from an unsigned zone.)  Only in
case (3) - signed, true absence of record - should you report NXDOMAIN.

Also, you forgot one:

6) redhat.com is signed, TLSA record is present in the domain, attacker
forges its *absence*.  This must also result in a SERVFAIL rather than
an NXDOMAIN condition, because the mail server is likely to go ahead
with opportunistic TLS, or even cleartext, if it gets NXDOMAIN.

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

Again, applications cannot be trusted to process AD correctly.  The
correct approach is for the resolver to hardcode a list of records that
*should* be passed through even if received from an unsigned zone: A,
AAAA, PTR, MX, SRV, TXT.  I think that's it.

zw