Open TheBlueMatt opened 4 years ago
Snawoot
commented
4 years ago 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
commented
4 years ago 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 notifications@github.com 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
commented
4 years ago 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:
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
commented
4 years ago 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
commented
3 years ago 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
commented
1 year ago 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
commented
1 year ago @oh2fih Agreed. PRs are welcome.
TheBlueMatt
commented
1 year ago I don't really think this is "closed", per se, more of "documented". Ideally MTA-STS wouldn't override DANE (even if that is super impractical with Postfix's current API - hence why Viktor, above, recommended simply not trying to use MTA-STS in Postfix - it's not currently a large value add compared to enabling DANE).
oh2fih
commented
1 year ago This is closed as it is not a bug in this software; postfix-mta-sts-resolver is a MTA-STS resolver & does this single task properly. The order of MTA-STS (or other TLS policy resolvers) & DANE is rather an issue with Postfix.
TheBlueMatt
commented
1 year ago Huh? This project violates the MTA-STS RFC, in a way which is impossible to integrate properly with Postfix in such a way that it properly implements MTA-STS. In practice, this project could properly implement MTA-STS (with some substantial questionable dependencies, eg the aiodns route mentioned at https://github.com/Snawoot/postfix-mta-sts-resolver/issues/67#issuecomment-653801866) or Postfix could be changed, or some additional library implementing the dns-based policy override could be developed. In any case, none of those exist today, so its not possible (without writing a bunch of additional software) to integrate this into a running Postfix system without violating the MTA-STS RFC in a way that substantially reduces in practice security of mail systems today - see Viktor's comment above on the number of mail services that implement only MTA-STS.
oh2fih
commented
1 year ago By its definition, postfix-mta-sts-resolver seems like a single-purpose building block; not an entire TLS enforcement solution. As such, it is a reasonable decision not to solve every problem regarding related technologies.
On the other hand, if postfix-mta-sts-resolver decided to support DANE policy lookups, it could simply forget about DNSSEC validation; it would be ok to respond with dane-only if the TLSA record was found and with secure if only MTA-STS was implemented. Postfix can handle the DNSSEC validation from there. It is the user's responsibility to ensure the overall operability.
Snawoot
commented
1 year ago I'll reopen it in case if someone is willing to add TLSA support to aiodns and pycares. It should be easier now as pycares uses vanilla C-Ares.
oh2fih
commented
11 months ago Snawoot
commented
11 months ago @oh2fih Would be nice to try. But as far as I understand, some entity still has to validate DNSSEC for that record. Does anyone know if Postfix validates them? or we should just trust results from resolver and it's server operator's responsibility to use DNSSEC-validating resolver?
TheBlueMatt
commented
11 months ago A resolver which has validated the records should set the AD (Authenticated Data) flag in the response, so generally we should just rely on that. Postfix/Exim do the same (but have a config option to control whether we trust that bit, effectively disabling DANE if that option is set to not trust).
oh2fih
commented
10 months ago Postfix has smtp_tls_security_level which could be dane for Opportunistic DANE TLS,
Opportunistic DANE TLS. At this security level, the TLS policy for the destination is obtained via DNSSEC. For TLSA policy to be in effect, the destination domain's containing DNS zone must be signed and the Postfix SMTP client's operating system must be configured to send its DNS queries to a recursive DNS nameserver that is able to validate the signed records.
...but which smtp_tls_policy_maps, having mta-sts-resolver as a socketmap:, overrides with secure. (This is exacly the problem this issue is about.)
The smtp_tls_security_level = dane can perform DNSSEC validations, if smtp_dns_support_level is set to dnssec.
The solution could be responding dane for cases where the TLSA record exists. That would cause Postfix to perform Opportunistic DANE TLS including the DNSSEC validation. The only problem here is that it would fall back to may unless it didn't find usable DNSSEC backed records, losing the secure from MTA-STS. But it would follow the RFC 8461, 2.
Responding dane-only would result in delivery failures in case there was a TLSA record but DNSSEC was not enabled for the zone, so dane would be better.
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.