Comments (16)
from postfix-mta-sts-resolver.
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.
from postfix-mta-sts-resolver.
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.
from postfix-mta-sts-resolver.
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.
from postfix-mta-sts-resolver.
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.
from postfix-mta-sts-resolver.
BTW, dnspython supports TLSA records, and it is capable of async DNS with trio. Could it be an option to switch to dnspython rather than wait until both pycares and aiodns implements the support (or accepts a pull request for it)?
from postfix-mta-sts-resolver.
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.
from postfix-mta-sts-resolver.
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.
from postfix-mta-sts-resolver.
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. Extendingaiodns
doesn't seem to be viable: it'll require to updatec-ares
(last attempt was largely ignored), then updatec-ares
fork insidepycares
along withpycares
itself and then updateaiodns
.dnspython
looks promising, but it'll take some effort to make it work in asynchronous fashion.
from postfix-mta-sts-resolver.
@oh2fih Agreed. PRs are welcome.
from postfix-mta-sts-resolver.
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).
from postfix-mta-sts-resolver.
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.
from postfix-mta-sts-resolver.
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 #67 (comment)) 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.
from postfix-mta-sts-resolver.
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.
from postfix-mta-sts-resolver.
@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?
from postfix-mta-sts-resolver.
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).
from postfix-mta-sts-resolver.
Related Issues (20)
- Client tls issue when using unix socket instead of inet tcp HOT 3
- dependencies unclear HOT 1
- Support unix sockets for daemon HOT 2
- Allow configuring the unix socket permissions HOT 1
- Policies for Smarthosts HOT 2
- Make systemd dependency optional HOT 4
- mta-sts-query returns NONE instead of FETCH_ERROR when DNS error HOT 1
- mta-sts-query documentation mentions verbosity, but it's not implemented HOT 2
- Notice for Postfix 3.4+ users HOT 2
- Postfix client TLS configuration problem when sending emails to google.com HOT 6
- MTA-STS fails with gmail.com HOT 5
- Move to aioredis v2 HOT 1
- TypeError HOT 3
- How to test successful postfix-mta-sts-resolver setup? HOT 5
- KeyError: 'url' with Debian Buster and python 3.7 HOT 1
- Allow configuring the unix socket owner and group HOT 3
- Querying IDN domains causes an error HOT 1
- Support for redis sentinel HOT 1
- Email deliverability fails to protonmail.com HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from postfix-mta-sts-resolver.