Re: [dane] An AD bit discussion (+concerns from glibc camp)

[Petr Spacek <[e-mail]>]

On 27.2.2014 21:04, Petr Spacek wrote:
>>>> For example current software like Postfix or OpenSSH client will
>>>> 'just work' without any change. AD bit will be handled in special
>>>> way only if the resolver library is initialized with the new call.
>>>
>>> As the developer of the Postfix DANE interface, I'd rather Postfix
>>> AD bit handling were subject to default system policy, and would
>>> ask the administrator to set system policy accordingly.  Once APIs
>>> for querying the stub-resolver behaviour (AD suppressed or trusted)
>>> become widely available, Postfix will start using them to sanity
>>> check its TLS policy settings (can't use DANE when stub resolver
>>> suppresses AD support).
> I 100 % agree with your point of view.
>
> The problem is that our glibc maintainer explicitly refused to change default
> behavior (i.e. mask AD bit until admin white-lists given resolver in
> /etc/resolv.conf) because it could break some (potentially) existing
> applications. That is a reason why we invented "init_trusted()" concept.
>
> Could you give us some detailed thoughts about compatibility?
>
> I guess that we will have the same discussion about compatibility again and
> again with many upstream developers from many DNS libraries so any detailed
> analysis will be handy.

I'm adding quote from our glibc maintainer:

 >>>> Carlos O'Donell <[e-mail]> wrote:
>>>>> Consider a RHEL7 or RHEL6 system using the present meaning of
>>>>> `nameserver' in /etc/resolv.conf, on a secure network with a trusted
>>>>> recursive resolver using DNSSEC for some given domains. In this
>>>>> configuration any application using the AD bit works as expected.
>>>>> The system administrators ensured there was trust between the recursive
>>>>> resolver and the client stub resolver. This is how a user might configure
>>>>> their corporate network, and even better they might also use 802.1x
>>>>> with no rogue or untrusted systems on their network.
>>>>>
>>>>> If we release a z-stream or y-stream glibc that inverts the definition
>>>>> of `nameserver' from trusted to untrusted (doesn't use EDNS0+DO for
>>>>> a query, and clears the AD bit) then applications in such a configuration
>>>>> as described above that rely on the AD bit forwarding may cease to
>>>>> function correctly.
>>>>>
>>>>> That is why I do not want to change the existing meaning of `nameserver'
>>>>> and why we should not change any of the existing meanings of entries in
>>>>> /etc/resolv.conf. Thus for compatibility I suggest adding a new option
>>>>> `untrusted' for use by such applications as NetworkManager to put
>>>>> untrusted DNS server (acquired from untrusted DHCP results) into.
>>>>>
>>>>> Let me be clear though, if I didn't care about breaking customer
>>>>> configurations, I'd make this change, but I think we would be doing
>>>>> a disservice to our users by breaking valid existing DNSSEC uses.

-- 
Petr^2 Spacek