On Sat, Jan 08, 2022 at 12:00:45PM +1100, raf wrote:
> When reading the documentation on smtp_tls_security_level, I thought
> dane-falling-back-to-encrypt seemed to be a missing option. But I
> thought it would never be used as a default, and for any non-default
> specific remote server, you're likely to know whether they do DANE or
> not, so you could always pick "dane" or "encrypt" for those.
>
> But it would be nice not to have to know whether a
> known peer has DANE or just TLS. After all, they might
> change their mind, start with just TLS, and then
> implement DANE later on.
>
> A security level that automatically upgraded from
> "encrypt" to "dane" when DANE becomes available seems
> like a good idea.
Perhaps the right insight is that DANE isn't a (local policy) TLS
security level like the others, rather DANE, when enabled *overrides*
the local security policy level with "more authoritative" information
about the TLS capabilities of the nexthop domain.
I can then refactor DANE, not as a security-level, but rather as a
feature you can enable or disable either globally or per-destination.
main.cf:
smtp_tls_dane_enable = yes
tls_policy:
example.org encrypt dane-enable=yes
example.com secure match=.example.com dane-enable=no
The "dane-only" level remains a true local policy partly supplemented
with remote detail, but the "dane" security level becomes a legacy
setting.
The question is then what to do about backwards compatibility for all
the users who have "smtp_tls_security_level = dane"? We would likely
need a second parameter to indicate the real security level when this is
the case. Something like:
main.cf:
smtp_tls_local_security_level = may | encrypt | ...
tls-policy:
example.org dane local_level=secure match=.example.org
which would then make for two ways to configure the same result, and so
perhaps, to keep things simpler, accept the fact that the interface is
not without a history, however imperfect, and pretend that "dane" is a
fully-fledged security level, but under the covers use
"smtp_tls_local_security_level" as the true underlying policy.
Either way, it becomes possible to honour RFC 8461 and prefer DANE to
MTA-STS when both are available, if the dynamic MTA-STS policy add-on
table returns "dane" and a local MTA-STS policy in case DANE is absent.
Turning "dane" into a non-level is cleaner in principle, but it may be
too late to completely change the design.
--
Viktor.
