FYI, Postfix smtp_tls_dane_insecure_mx_policy is being fixed

[wietse-postfix]

There was some discussion on the postfix-users mailing list about unexpected behavior of the smtp_tls_dane_insecure_mx_policy setting. This was the result of a bad change in the default value that was introduced in Postfix 3.6.

The change is being reverted to the default that was in effect with Postfix 3.5 and earlier: the fixed default setting is smtp_tls_dane_insecure_mx_policy = dane. There will be updated releases for Postfix 3.6..3.10.

[DragonWork]

To add some details for the interested postmasters:

The bug caused some emails to unexpectedly downgrade to weaker encryption (and plaintext in theory) instead of using opportunistic DANE when it was available and requested by a policy table.

This issue only affected cases where smtp_tls_policy_maps (whether a server or database/file) returned dane (but not dane-only) for a domain. If smtp_tls_security_level was set to anything other than dane (e. g. may or encrypt), Postfix did not apply opportunistic DANE as expected. As a result, emails to DANE-supporting mail servers — whose MX records were looked up via insecure means (i. e. not DNSSEC signed) — were not encrypted with DANE, even though the policy map explicitly requested it.

To clarify: This issue does not impact mandatory DANE (dane-only). It only affects opportunistic DANE (dane) in cases where the domain itself is not DNSSEC-signed, but its MX servers support DANE and are signed (and smtp_tls_security_level ≠ dane). This issue typically arises when users with custom domains use external MX providers. Since the MX lookups are not signed, this path is inherently less secure than mandatory DANE, anyway.

To fix this, the default setting is being restored to smtp_tls_dane_insecure_mx_policy = dane, irrespective of smtp_tls_security_level. This ensures that opportunistic DANE works correctly in all situations.
You can manually set this variable as a workaround until the fix is released.

[jahlives]

The TLS policy for MX hosts with "secure" TLSA records when the nexthop destination security level is dane, but the MX record was found via an "insecure" MX lookup

just for my understanding ;-) Does this mean that with this setting dane is performed even the parent zone containing the MX is not dnssec secured?

[DragonWork]

The TLS policy for MX hosts with "secure" TLSA records when the nexthop destination security level is dane, but the MX record was found via an "insecure" MX lookup

just for my understanding ;-) Does this mean that with this setting dane is performed even the parent zone containing the MX is not dnssec secured?

Basically yes. Not as secure as mandatory DANE, but still better than the alternative: unauthenticated TLS or trusted TLS via classical Certification Authorities.

PS: This already happens on your setup with your default smtp_tls_security_level = dane.

[jahlives]

nice feature :-) But an attacker in position to spoof DNS replies could "insert" a higher (lower) prio MX with no TLSA records and then postfix would connect with may to that server?

[DragonWork]

nice feature :-) But an attacker in position to spoof DNS replies could "insert" a higher (lower) prio MX with no TLSA records and then postfix would connect with may to that server?

This is why it's called insecure MX lookup.
Only mandatory DANE is protected against forgery starting from the very root of the DNS hierarchy.

An attacker capable of manipulating any non-DNSSEC signed data also could add a trusted TLS certificate for its own domain (say Letsencrypt for smtp.maliciousprovider.com) and redirect the mails, even with opportunistic DANE disabled. Postfix would log "trusted connection established". So this isn't a problem introduced by opportunistic DANE.

PS: This is not really a feature, Postfix does this since the first implementation of DANE support. It is just about a bug that prevents the expected behavior under some very limited scenarios. This is why Wietse is going to push a patch to every supported minor version.