On Fri, Apr 17, 2020 at 08:13:52PM +0200, Florian Weimer wrote:
> > Correct. Until now, Postfix asserts RES_USE_DNSSEC to request
> > validation in a resolver.
>
> RES_USE_DNSSEC is unfortunately misnamed. [...]
Thanks, but neither Wietse nor I need a refresher on DNSSEC.
> > The sysadmin has responsibility to ensure that (the path to) their
> > resolver is secure.
>
> But it often was not, so the AD bit is not a strong indicator.
Postfix does not care whether the AD is 0 or 1 except when configured to
do DANE. The documentation on enabling DANE clearly indicates that a
trusted local resolver is required.
If the administrator does not bother to ensure that's the case, they're
no worse off than before, with ordinary opportunistic TLS. Perhaps some
have a false of security, so be it.
We can't preclude every possible way for the administrator to be
negligent. We do however have a duty to administrators who paid
attention, and set things up correctly, to not have their systems break
unexpectedly. So we're optimising for those who did it right, and not
for those who were negligent.
> > Any 'improvements' in Postfix DNSSEC support will have to be developed
> > in the Postfix 3.6 release cycle. The results from those 'improvements'
> > will never be merged back into Postfix 3.5 and earlier.
>
> I'm trying to understand why you were trusting the AD bit. Is it
> because you consider the requirement in the RFC to perform DNSSEC
> validation optional?
The RFC requirement is more than optional, it is unrealistic. Doing
DNSSEC-validation in each application is not practical, there is no
broadly deployed (on all the BSDs, Linux, Solaris, ...) library that
does this, and each application would potentially need its own
implementation of RFC-5011 trust-anchor rollover, ... and the library
would need to evolve to add/deprecate DNSSEC algorithms in a timely
manner...
It is much saner to delegate DNSSEC validation to the local resolver,
and trust its output. That resolver can track root key changes,
implement new algorithms, deprecated old ones, support administrative
"NTAs" (negative trust-anchors for work-arounds to known breakage),
set the AD-bit for local authoritative data, ...
If you want to enhance the stub resolver in Glibc to be a validating
stub resolver, and return the AD bit only for validated data, feel
free, but Postfix is not about to do that internally.
Perhaps some day we'll have support for multiple DNS backends, e.g.
libunbound or libldns, which do support validation, but even then
it is not clear how that'll be managed w.r.t. trust-anchor updates,
NTAs, algorithm policy, ...
> We looked at this and thought we needed the flag masking in glibc,
> with an explicit configuration decision (at the glibc layer) to mark
> the resolvers as trusted to handle the AD bit as expected.
This may be appopriate for client applications which don't expect much
or any explicit administrator configuration. For an MTA like Postfix,
DANE is not yet the default policy, and we expect any administrator who
enables DANE to have taken the time to ensure the basic requirements are
met.
The Glibc change may at some point facilitate enabling DANE by default,
with little administrator intervention, e.g. when "trust-ad" is in the
default resolver flags. So, ultimately, I'm sympathetic to the change,
but presently we need to ensure backwards-compatible behaviour for the
stable Postfix releases for the administrators who've been doing the
right thing all along.
> The behavior is already configurable at the glibc layer. It does not
> make sense to me to add another knob to Postfix itself.
I expect that "options trust-ad" is quite likely to be missing as
upgrades to 2.31 start happening in the near-term.
> My worry here is that if Postfix (as the de-facto secure mailer) uses
> RES_TRUSTAD in this way, others will follow suit, and then libraries
> can no longer use the AD bit to indicate successful DNSSEC validation.
Postfix will likely have more sophisticated handling of RES_TRUSTAD in
the 3.6 release circa Feb 2021, and perhaps by then NetworkManager and
the like will begin to have better management of the new resolv.conf
option (though I expect it will take some time for such changes to
show up in distributions).
A better sequence of events would have been:
1. Glibc is updated to silently skip the "trust-ad" option
(perhaps it already skip unknown options...).
2. Software that manages resolv.conf(5) is updated to set the
trust-ad bit as appropriate
3. Some time goes by allowing for 2) to be widely deployed.
4. Glibc is updated to implement the "trust-ad" option, which
is in practice already set in resol.conf(5) when appropriate.
With the Glibc change as the first step, we have no choice but to
restore the status quo ante.
--
Viktor.
