[pfx] Re: mta-sts and smtp_tls_security_level
On Sat, Mar 09, 2024 at 07:21:53PM +0100, Joachim Lindenberg via Postfix-users wrote: > I thought almost all cloud providers use anycast these days, > elminating the need to serve different IPs per region. No. That's not the case. Anycast is a useful tool, but isn't the whole story. The responses vary by location and over time within the same location. - NYC: $ dig +short -t a www.google.com 142.250.65.196 ... a few minutes later ... $ dig +short -t a www.google.com 142.250.176.196 - LAX: $ dig +short -t a www.google.com 142.250.72.132 ... a few minutes later ... $ dig +short -t a www.google.com 142.250.188.228 - MEL: $ dig +short -t a www.google.com 142.250.70.228 - MUC: $ dig +short -t a www.google.com 142.250.186.164 -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: mta-sts and smtp_tls_security_level
I thought almost all cloud providers use anycast these days, elminating the need to serve different IPs per region. Joachim -Ursprüngliche Nachricht- Von: Viktor Dukhovni via Postfix-users Gesendet: Samstag, 9. März 2024 18:42 An: postfix-users@postfix.org Betreff: [pfx] Re: mta-sts and smtp_tls_security_level On Sat, Mar 09, 2024 at 10:46:17AM +0100, Joachim Lindenberg via Postfix-users wrote: > > Viktor Dukhovni: > > not sufficient market pressure to make it a priority. > Unfortunately yes, not yet. > > various load balancers would need to do online DNSSEC signing > Can you please elaborate why that should be required? Some of the load balancing is DNS-based, directing users to "nearby" datacentre locations, that are currently up and not experiencing overload. So names like "www.google.com" have return addresses with short TTLs and different content for different queries. Static DNSSEC signing is a poor fit for this, so signing needs to be on-the-fly. Cloudflare does this, so there a proof of concept, but it is a non-trivial implementation requiring some engineering effort, well beyond just spinning up BIND or Knot for a statically signed zone. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: mta-sts and smtp_tls_security_level
On Sat, Mar 09, 2024 at 10:46:17AM +0100, Joachim Lindenberg via Postfix-users wrote: > > Viktor Dukhovni: > > not sufficient market pressure to make it a priority. > Unfortunately yes, not yet. > > various load balancers would need to do online DNSSEC signing > Can you please elaborate why that should be required? Some of the load balancing is DNS-based, directing users to "nearby" datacentre locations, that are currently up and not experiencing overload. So names like "www.google.com" have return addresses with short TTLs and different content for different queries. Static DNSSEC signing is a poor fit for this, so signing needs to be on-the-fly. Cloudflare does this, so there a proof of concept, but it is a non-trivial implementation requiring some engineering effort, well beyond just spinning up BIND or Knot for a statically signed zone. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: mta-sts and smtp_tls_security_level
> Viktor Dukhovni: > not sufficient market pressure to make it a priority. Unfortunately yes, not yet. > various load balancers would need to do online DNSSEC signing Can you please elaborate why that should be required? Thanks, Joachim ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: mta-sts and smtp_tls_security_level
On Fri, Mar 08, 2024 at 11:11:40PM +0100, Joachim Lindenberg via Postfix-users wrote: > But is there any reason that prevents google to use DNSSEC other than > the arrogance of power? My read is that there is not sufficient market pressure to make it a priority. Robust implementation at scale is non-trivial, (various load balancers would need to do online DNSSEC signing) and resources for work that is not a business priority are scarce. I can more easily see "gmail.com" being signed, but even there the incentives need to get stronger before that happens. Yes, mta-sts is an ugly hack that makes it possible to somewhat sweep the problem under the rug. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: mta-sts and smtp_tls_security_level
But is there any reason that prevents google to use DNSSEC other than the arrogance of power? Imho it is obvious that mta-sts is only useful for big players that prefer to ignore destinations not in their cache. For the rest of us, mta-sts is inferior to smtp-dane. Joachim -Ursprüngliche Nachricht- Von: Viktor Dukhovni via Postfix-users Gesendet: Freitag, 8. März 2024 22:44 An: postfix-users@postfix.org Betreff: [pfx] Re: mta-sts and smtp_tls_security_level On Fri, Mar 08, 2024 at 10:01:29PM +0100, Joachim Lindenberg via Postfix-users wrote: > Imho you get pretty close to mta-sts if you use verify together with a > DNSSEC-validating resolver. You just validate the "authorized" MTAs by > different means. Yes, but google.com and yahoo.com (the domains mentioned by the OP), are not presently DNSSEC-signed. :-( -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: mta-sts and smtp_tls_security_level
On Fri, Mar 08, 2024 at 10:01:29PM +0100, Joachim Lindenberg via Postfix-users wrote: > Imho you get pretty close to mta-sts if you use verify together with a > DNSSEC-validating resolver. You just validate the "authorized" MTAs by > different means. Yes, but google.com and yahoo.com (the domains mentioned by the OP), are not presently DNSSEC-signed. :-( -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: mta-sts and smtp_tls_security_level
Imho you get pretty close to mta-sts if you use verify together with a DNSSEC-validating resolver. You just validate the "authorized" MTAs by different means. I still think SMTP-DANE (RFC 7672) is preferrable. Regards, Joachim -Ursprüngliche Nachricht- Von: Michael W. Lucas via Postfix-users Gesendet: Freitag, 8. März 2024 21:35 An: postfix-users@postfix.org; Viktor Dukhovni Betreff: [pfx] Re: mta-sts and smtp_tls_security_level On Fri, Mar 08, 2024 at 03:05:43PM -0500, Viktor Dukhovni via Postfix-users wrote: > On Fri, Mar 08, 2024 at 01:28:00PM -0500, Michael W. Lucas via Postfix-users > wrote: > > > Realistically, Gmail and Yahoo do not care about my MTA-STS reports. > > All they care about is that I validate their X.509 certs. > > > > Is there any reason to use something like mta-sts-daemon in that > > transport instead of just setting smtp_tls_security_level=verify ? > > Just using verify leaves you more vulnerable to DNS-based MiTM > attacks, because "verify" uses unvalidated MX hostnames as the > "reference identifiers" in certificate matching. > > With "mta-sts", you are expected to obtain a trusted copy of the MX > host list via HTTPS (trusting one of various WebPKI CAs to > authenticate the website). The attacker first has to obtain a forged > certificate for "mta-sts.", and then forged certificates > for one of the MX hosts. > > If you independently obtain, and periodically recheck, the list of MX > hosts for one or more domains, you can use a TLS policy that lists > those names as the names to check, with either "verify" or "secure", > which are identical once you explicitly specify the match names. > > example.com secure match=mx1.example.com:mx2.example.com Ah! Very clear, thank you. That's the last thing I need to finish this silly book. ==ml -- Michael W. Lucashttps://mwl.io/ author of: Absolute OpenBSD, SSH Mastery, git commit murder, Absolute FreeBSD, Butterfly Stomp Waltz, TLS Mastery, etc... ### New books: DNSSEC Mastery, Letters to ed(1), $ git sync murder ### ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: mta-sts and smtp_tls_security_level
On Fri, Mar 08, 2024 at 03:05:43PM -0500, Viktor Dukhovni via Postfix-users wrote: > On Fri, Mar 08, 2024 at 01:28:00PM -0500, Michael W. Lucas via Postfix-users > wrote: > > > Realistically, Gmail and Yahoo do not care about my MTA-STS > > reports. All they care about is that I validate their X.509 certs. > > > > Is there any reason to use something like mta-sts-daemon in that > > transport instead of just setting smtp_tls_security_level=verify ? > > Just using verify leaves you more vulnerable to DNS-based MiTM attacks, > because "verify" uses unvalidated MX hostnames as the "reference > identifiers" in certificate matching. > > With "mta-sts", you are expected to obtain a trusted copy of the MX host > list via HTTPS (trusting one of various WebPKI CAs to authenticate the > website). The attacker first has to obtain a forged certificate for > "mta-sts.", and then forged certificates for one of the > MX hosts. > > If you independently obtain, and periodically recheck, the list of MX > hosts for one or more domains, you can use a TLS policy that lists > those names as the names to check, with either "verify" or "secure", > which are identical once you explicitly specify the match names. > > example.com secure match=mx1.example.com:mx2.example.com Ah! Very clear, thank you. That's the last thing I need to finish this silly book. ==ml -- Michael W. Lucashttps://mwl.io/ author of: Absolute OpenBSD, SSH Mastery, git commit murder, Absolute FreeBSD, Butterfly Stomp Waltz, TLS Mastery, etc... ### New books: DNSSEC Mastery, Letters to ed(1), $ git sync murder ### ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: mta-sts and smtp_tls_security_level
On Fri, Mar 08, 2024 at 01:28:00PM -0500, Michael W. Lucas via Postfix-users wrote: > Realistically, Gmail and Yahoo do not care about my MTA-STS > reports. All they care about is that I validate their X.509 certs. > > Is there any reason to use something like mta-sts-daemon in that > transport instead of just setting smtp_tls_security_level=verify ? Just using verify leaves you more vulnerable to DNS-based MiTM attacks, because "verify" uses unvalidated MX hostnames as the "reference identifiers" in certificate matching. With "mta-sts", you are expected to obtain a trusted copy of the MX host list via HTTPS (trusting one of various WebPKI CAs to authenticate the website). The attacker first has to obtain a forged certificate for "mta-sts.", and then forged certificates for one of the MX hosts. If you independently obtain, and periodically recheck, the list of MX hosts for one or more domains, you can use a TLS policy that lists those names as the names to check, with either "verify" or "secure", which are identical once you explicitly specify the match names. example.com secure match=mx1.example.com:mx2.example.com -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
