On Sun, Feb 06, 2022 at 12:34:02PM -0500, Wietse Venema wrote:
> Postfix turns on DNSSEC when DANE is enabled. Postfix does not turn on
> DNSSEC by default, because that is not a practical option at this
> time.
On Sun, Feb 06, 2022 at 06:38:10PM +0100, Joachim Lindenberg wrote:
> There is a distinct setting smtp_dns_support_level = dnssec in
> main.cf. Doing the extra lookups seems doable to me (not looking at
> the source code so far).
It's not so much that enabling RES_USE_DNSSEC is impractical, but rather
that it is often ineffective, because many Postfix administrators don't,
either at all or exclusively, use a local validating resolver.
When the configured iterative DNS resolver is remote, trusting its AD
bit does not add meaningful protection against active MiTM attacks.
This is why DNSSEC is off by default, and should only be enabled by
users who make the effort to deploy a local validating resolver, and
ensure that /etc/resolv.conf lists only 127.0.0.1 (and/or ::1, or
some suitable "loopback" address).
As for refactoring DANE as a conditional override of local TLS policy,
rather than a replacement of local policy, this has been discussed (see
the list archives), but we haven't settled on a design.
I don't think it makes sense for DANE to unconditionally trump local
policy, it must be possible to disable it for some or all domains.
However, making it possible for DANE to fall through to ambient
local policy does make sense. We just need a sensible design
that is backwards compatible and sufficiently expressive in
policy tables etc.
The basic observation is perhaps that "dane-only" is a "real" local
policy security level, but "dane" (RFC7672 "Opportunistic DANE TLS") is
perhaps not a security level, but rather a conditional override of local
policy to "dane-only" when remote TLSA records are detected.
This suggests that "Opportunistic DANE TLS" needs a separate control
knob, that augments rather than conflicts with other local policy
settings, but can also be turned on/off in the policy table.
This can also resolve the conflict between MTA-STS and DANE, with
DANE winning when enabled (thus conforming to RFC8461).
So the issue is not so much whether to enable opportunistic DANE TLS by
default, but rather whether enabling it conflicts with specifying the
ambient local policy that is effect absent DANE TLSA records.
--
Viktor.
