MTA-STS Overrides DANE

[TheBlueMatt]

I don't know of a good domain to generate a test-case for, sadly, so apologies if this isn't true, but from my understanding of the integration flow, it seems like using this in smtp_tls_policy_maps would result in MTA-STS overriding DANE, which seems like a pretty severe security downgrade for domains which use both (eg protonmail). Doing a DANE lookup in postfix-mta-sts-resolver before returning MTA-STS results seems somewhat overcomplicated, so it would certainly be more ideal if postfix had a way to capture this policy in its config (ie "DANE-but-fall-back-to-verify"), but presuming both use the same (caching) DNS resolver and the TLSA record has a reasonable TTL, doing a DANE check first shouldn't have much of a performance hit nor be too brittle.

[Snawoot]

Hello!

postfix-mta-sts-resolver either retrieves enforcing TLS policy or clearly indicates it has no TLS policy override for requested domain. In later case next policy map or default TLS policy applies, which is presumably DANE.

Once STS policy is discovered, authenticated encryption is mandatory. So, STS is not weaker than DANE since the moment policy was discovered.

[TheBlueMatt]

Unlike MTA-STS, DANE specifies a particular public key (hash), which is much more specific than a hostname. This allows DANE hosts to bypass the CA mess entirely. RFC 8461 appears to agree, stating “ in particular, senders who implement MTA-STS validation MUST NOT allow MTA-STS Policy validation to override a failing DANE validation.”

…

On Jul 4, 2020, at 03:29, Snawoot ***@***.***> wrote:  Hello! postfix-mta-sts-resolver either retrieves enforcing TLS policy or clearly indicates it has no TLS policy override for requested domain. In later case next policy map or default TLS policy applies, which is presumably DANE. Once STS policy is discovered, authenticated encryption is mandatory. So, STS is not weaker than DANE since the moment policy was discovered. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[Snawoot]

In fact, DANE doesn't bypasses CA, it just uses another root of trust which has no alternatives.

However, you are right. Proper solution should restrict certificates to set of least common properties defined by both policies. It doesn't appear to be possible with current client TLS support in Postfix. Strict priority of DNSSEC trust root over PKIX trust root and vice versa doesn't seem right either.

But you still can achieve DANE preference using separate policy map which takes precedence before MTA-STS map and provides dane-only policy. It's even possible to make this map dynamic (just as postfix-mta-sts-resolver) and do lookups for "usable" TLSA records. Also note that just dane policy may result opportunistic encryption if no usable TLSA records found.

It's possible to add such feature in pmsr, but:

• It doesn't seem to be much of improvement, it's just a bias in another direction. However, some may consider this arguably better direction for MTA-STS and DANE overlap case.
• It'll require to replace aiodns library with something what supports TLSA. Extending aiodns doesn't seem to be viable: it'll require to update c-ares (last attempt was largely ignored), then update c-ares fork inside pycares along with pycares itself and then update aiodns. dnspython looks promising, but it'll take some effort to make it work in asynchronous fashion.

[TheBlueMatt]

Also relevant is today's thread on postfix-users. Viktor noted that, per his dataset, there is very, very little overlap in MTA-STS and DANE today, so its not a high priority issue unless you're sending to a bunch of tutanota or Protonmail users today, but it likely will be more pressing in 2021 with Microsoft Hotmain/Outlook/hosted customers moving in that direction.

Also likely worth mentioning here, that, given the assumption that you can add a DNSSEC-validating record to a domain's DNS zone, you can in nearly every case get a CA-verified certificate issued within a few seconds, so it is likely strictly more restrictive than the traditional TLS CA infrastructure, though, indeed, its just a different CA.

[vdukhovni]

FWIW, my advice is to not bother implementing MTA-STS as such.

You can, if you wish, take a few of the top domains that have enabled MTA-STS (gmail.com, mail.ru and perhaps a few more) and periodically update a policy table for these by probing for their MTA-STS records. This is much more robust and efficient than trying to do MTA-STS for all domains, given how few have it enabled, and the possibility of bypassing DANE, which provides stronger protection.

Overlap domains include, for example, protonmail.ch, comcast.net, web.de and mail.com and it is best to use DANE for these rather than MTA-STS.

Support for MTA-STS legitimises Google's ongoing avoidance of DANE, we should return the favour.

[oh2fih]

Overriding DANE is directly against the RFC 8461, 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.

The main reason is that MTA-STS is vulnerable to downgrade attacks preventing policy discovery; from 10.2:

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.

However, I agree that this is primarily a problem of the Postfix for implementing the DANE support in a way that allows smtp_tls_policy_maps override the entire DANE verification. They could provide a lookup table service for DANE that could be placed before other lookup tables.

If this project decides not to implement DANE lookups as a feature, this should at least be added to the README.md, possibly at the top of the "Current support of RFC8461 is limited" list. The README.md should remind the users to decide whether they want strictly follow the specification or settle with this limitation in Postfix's TLS policy maps.

[Snawoot]

@oh2fih Agreed. PRs are welcome.