Re: [dane] An AD bit discussion

[Petr Spacek <[e-mail]>]

On 26.2.2014 18:24, Tony Finch wrote:
> Paul Wouters <[e-mail]> wrote:
>> 1 Applications can either do dnssec validation themselves, or trust the
>>    AD bit.
>
> At the moment I consider in-process validation to be the safer way to do
> it, because apps do not have any sane way to verify that it is safe to
> trust the AD bit (more about that below). That is, by doing its own
> validation the app is better able to guarantee safety, without assuming
> that there is an expert and diligent sysadmin who is able to do arcane
> things like override the DHCP server's suggested nameserver addresses.
A proposal sent to the other thread
(http://www.ietf.org/mail-archive/web/dane/current/msg06475.html)
attempts to address this problem with explicit name server white-listing.

>> 2 It is undesirable that each application has its own DNSSEC validation
>>    code, trust anchors and DNS cache.
>
> Agreed, but there are some subtleties. It's probably not too bad if the
> validation code is in a shared library that is centrally configured - like
> the traditional resolver or ldns's resolver. However if ldns's resolver
> were to be more widely used it will need MUCH better trust anchor
> management. Even so a system-wide cache should perform better. Perhaps
> multi-user systems should have per-user validating caches so that users
> don't have to trust each other too much :-)
The mentioned proposal calls for per-system centralized trust anchor management.

>> 3 It is undesirable that applications blindly trust the AD bit when
>>    resolv.conf points to another host as the AD bit could have been modified
>>    on the network.
>
> Right. What makes this particularly pernicious is that the resolver API
> does not give an app any reasonable way to find out if it would be safe to
> trust the AD bit.
This is exactly the reason why we propose to strip the AD bit in library so 
application don't need to think about it's trustworthiness.

>> 4 In the ideal world tomorrow, each host has its own automatically
>>    configured, perfectly working validing DNS server and resolv.conf can
>>    be ignored or is always hardcoded with nameserver 127.0.0.1
>
> That would be nice :-)
>
>> Now for my question. Until we reach 4), what should we do with the AD
>> bit in getaddrinfo() ?
>>
>> A) strip the AD bit in struct addrinfo for "untrusted nameservers". A new
>>     configuration mechanism will allow white-listing nameservers and 127.0.0.1
>>     will always be on the whitelist.
>
> That sounds like a fair plan.
>
> Note that what ssh does is use the low-level res_query() API which returns
> a raw DNS packet, and examines the AD bit in the packet header.
> http://svnweb.freebsd.org/base/vendor-crypto/openssh/6.5p1/openbsd-compat/getrrsetbyname.c?revision=261288&view=markup#l274
> Exim's preliminary DNSSEC support does the same.
> http://git.exim.org/exim.git/blob/HEAD:/src/src/dns.c#l430
>
> So you should change the low-level parts of the traditional resolver to
> clear the AD bit in the packet header before returning to any higher level
> code, unless the connection to the nameserver is known to be safe.
Note we are not trying to 'target' one particular library. It would be great 
if we can reach consensus on some universal approach and then actively work 
with DNS library maintainers to add the new behavior to DNS libraries.

> Question: along with this change are you planning to change the resolver
> to set the AD flag in queries when the nameserver is known to be safe?
>
> Usually the AD flag only appears in responses if the query had the AD or
> DO flags set. DO is a bit wasteful for clients that only care about the AD
> bit. However the only DNSSEC switch that libc resolvers currently have is
> options edns0 (which implies DO).
Could you elaborate on reasons for setting AD=1, please?

-- 
Petr Spacek  @  Red Hat  @  Brno office