Dear Postfix folks,
Running the *Public Email & DNS Testbed* [1], I was reminded, that we
have MTA-STS set up, but do not take the MTAT-STS policy of other
domains into account.
As a solution I found *postfix-mta-sts-resolver* [2], which warns about
a “RFC violation” [3]:
### Warning: MTA-STS policy overrides DANE TLS authentication
Due to Postfix's limitations, a resolved MTA-STS policy overrides DANE TLS
authentication ([RFC 6698](https://www.rfc-editor.org/rfc/rfc6698)), because
DANE is an internal feature of Postfix, and the postfix-mta-sts-resolver always
responds with a
([`smtp_tls_policy_maps`](https://www.postfix.org/postconf.5.html#smtp_tls_policy_maps))
lookup result `secure` for [Secure server certificate
verification](https://www.postfix.org/TLS_README.html#client_tls_secure).
* The resulting behaviour is against [RFC 8461,
2](https://www.rfc-editor.org/rfc/rfc8461#section-2):
> However, MTA-STS is designed not to interfere with DANE deployments when
the two overlap; in particular, senders who implement MTA-STS validation MUST NOT
allow MTA-STS Policy validation to override a failing DANE validation.
Domains implementing both MTA-STS and DANE probably want DANE to be preferred:
* DANE allows strict binding of certificates; the policy can authorize only a certain certificate or certificates from a certain CA. With MTA-STS, a certificate from any trusted CA is automatically trusted; [RFC 8461, 10.1](https://www.rfc-editor.org/rfc/rfc8461#section-10.1):
> SMTP MTA-STS relies on certificate validation via PKIX-based TLS
identity checking [RFC6125]. Attackers who are able to obtain a
valid certificate for the targeted recipient mail service (e.g., by
compromising a CA) are thus able to circumvent STS authentication.
* Based on DNSSEC, DANE not vulnerable to downgrade attack that could prevent policy discovery. MTA-STS security considerations acknowledges this weakness in [RFC 8461, 10.2](https://www.rfc-editor.org/rfc/rfc8461#section-10.2):
> Since MTA-STS uses DNS TXT records for policy discovery, an attacker
who is able to block DNS responses can suppress the discovery of an
MTA-STS Policy, making the Policy Domain appear not to have an MTA-STS Policy.
> Resistance to downgrade attacks of this nature -- due to the ability to
authoritatively determine "lack of a record" even for non-participating recipients
-- is a feature of DANE, due to its use of DNSSEC for policy discovery.
* The postfix-mta-sts-resolver does not intent to implement policy lookups
for DANE, and responses other than `secure` with `match=` would not verify the
TLS certificate as required by [RFC 8461,
4,2](https://www.rfc-editor.org/rfc/rfc8461#section-4.2).
If you wish to meet this requirement:
* List a DANE policy resolver responding with `dane-only` (for [Mandatory
DANE](https://www.postfix.org/TLS_README.html#client_tls_dane)) before
postfix-mta-sts-resolver in `smtp_tls_policy_maps` lookup table list.
* Alternatively, you could use a static lookup table for domains known to implement both MTA-STS & DANE, e.g.,
```
smtp_tls_policy_maps =
hash:/etc/postfix/tls_policy,socketmap:inet:127.0.0.1:8461:postfix
```
Do you know of other solutions?
Kind regards,
Paul
[1]: https://www.email-security-scans.org/
[2]: https://github.com/Snawoot/postfix-mta-sts-resolver
[3]:
https://raw.githubusercontent.com/Snawoot/postfix-mta-sts-resolver/master/README.md
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
