Comcast Shot Themselves in the Foot with MTA-STS
agwa.name
agwa.name
> the MX record is vulnerable to manipulation unless DNSSEC is used, but people don't like DNSSEC which is why MTA-STS was invented
This speaks volumes about the way these protocols are developed and subsequently implemented in software. People are not going to like complex solutions and that should be kept in mind when those protocols are being developed and implemented, otherwise its deployment is hampered just like we're seeing now with DNSSEC. In fact, now we've got MTA-STS because "people don't like DNSSEC", involving a whole HTTPS stack on both sides with so much more failure points just to send an email.
The author themselves states in a different post on their blog that DNSSEC is avoided like the plague because it is a royal pain in the ass to set up and outages at major corporations (coughSlackcough) that clearly have talented, knowledgeable, experienced ops people show that the standard was not designed with practical implementation in mind.
"Security that is difficult to implement and can cause catastrophic-level outages not used by majority of internet; film at 11."
Instead of lecturing everyone on how they should be using DNSSEC, what we should be doing is working on "DNSSEC 2.0", from lessons learned in the 2-3 decades people have been trying to use DNSSEC.
But DNSSEC 2.0 is unlikely to happen, because DoH solves most of the real-world on-the-wire problems with DNS security. There have always been two visions for how to secure the DNS: the top-down way, with signatures rolling down from the roots, a la DNSSEC, and the bottom-up way, where leaf servers allow individual clients to make secure queries, and we gradually converge on a secure DNS as more and more leafs make secure queries available. Top-down won at the IETF, but bottom-up is going to win the market.
It may turn out that DNSSEC is useful, for exactly one thing: downloading the root zone securely. This circumvents any refusal to do signing-on-the-server by the root zone server operators.
Here are the instructions: https://localroot.isi.edu/
https://datatracker.ietf.org/doc/html/draft-ietf-sipp-ipae-t...
Twenty-six years later, we're still waiting for IPv6 to be considered "the Internet".
> dig +dnssec comcast.net MX
This has nothing to do with DNSSEC.
But if the ecosystem as a whole was happy about DNSSEC and DANE, it's somewhat doubtful we'd have both specs and the involvement of https.
First is certificate management. There is currently no automated way for mail providers to obtain TLS certificates for domains whose MX records point to them - i.e. there is no SMTP/MX equivalent to the Baseline Requirement's "Agreed-Upon Change to Website" domain validation method, or ACME's HTTP-01 challenge type. And in general domain operators don't want their mail providers to have certificates which could be used to impersonate their websites.
The certificate problem could be solved with SRVName certificates, which permit certificates to be scoped to a particular service on a host. Combined with an automated SMTP/MX-based validation method, this would permit mail providers to easily and securely get certificates for the domains whose mail they host. But there are thorny security-critical compatibility problems which are blocking the deployment of SRVName certificates. I wrote about the problem near the end of this blog post: https://www.agwa.name/blog/post/avoiding_dnssec
Second is that you need a mechanism for servers to remember that they should use TLS with a particular recipient domain, similar to HSTS. This could probably be accomplished with a simple SMTP extension that's included in the EHLO response.
> The certificate problem could be solved with SRVName certificates, which permit certificates to be scoped to a particular service on a host.
What about extended key usage extension, doesn't it function similarly without needing to fiddle with SANs? https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1....
Are there any situations today where that happens?
edit: I actually read the spec, and apparently the listing of allowed servers is a side aspect of the spec, the main meat is opting in to tls overall; that was not immediately obvious from the article. In that context your question makes more sense. To answer more comprehensively, I don't see why similar mechanism that functions well with HTTP would not work here; that the server would send STS policy to the client after connection which the client then caches and consults on subsequent connections. This is how HSTS works.
Is this just a way of validating the MX record? That is, the public MX record in DNS can't be trusted, but because a cert verifies the identity of the sending mail server, the one they send can be trusted?
If someone is successfully impersonating the sender, what stops them from sending a false MX record. If they aren't impersonators, why not just trust them regardless - why do they need the MX record?
Obviously, I'm missing something.
Maybe I should just look it up myself!
e.g.
dig +short mx2h1.comcast.net
96.102.157.179
dig +short mx1a1.comcast.net
96.103.145.165
In that case I would suggest they did not really shoot themselves in the feet. Rather they may have stubbed their toe.
Of course the MTA probably should provide ways for admins to override this. Maybe as simple as deleting a file, modifying a sql(ite) DB.
Kind of. The max_age in the text file is the max time a cached policy should be used if a new policy can't be retrieved (e.g. it's being blocked by an attacker). If a new policy can be retrieved over HTTPS, it's totally OK to use it even if the max_age of the cached policy isn't up yet.
Thus, tyingq's suggestion is reasonable. In fact, the RFC already tells mail servers to look for a new policy if just one MTA-STS failure occurs (https://datatracker.ietf.org/doc/html/rfc8461#section-5.1 step 3). The problem is that it checks for a new policy using the ID in the TXT record, which as explained in the blog post is unreliable.
It seems silly to introduce that extra level of indirection when there's already a well-known URL to try to fetch a new version.
Is there any rationale for this? Also if DNS is explicitly a not trusted component this seems to strictly lead to a less secure system :o
(But I guess the designers did not want to "completely" override MX records just with yet another out of band magic.)
Do you mean for the TXT record? The rationale for that was performance. I don't know if this rationale was backed up by hard data or just a theoretical concern that HTTPS requests are more expensive than DNS requests.
> Also if DNS is explicitly a not trusted component this seems to strictly lead to a less secure system
The TXT record doesn't contain any security-sensitive information so it doesn't actually reduce security. The worst an attacker can do is block the retrieval of a new policy, but they could also accomplish this by removing the mta-sts A/AAAA record. Either way, the cached policy will be used until its max_age expires.
I mean that during the max_age time the MTA knows that the target MTA has/had a policy, so it could directly query that again instead of doing the DNS lookup. But probably the spec writers did not want to risk MTAs getting hammered with HTTPS requests on every failure.
> Either way, the cached policy will be used until its max_age expires.
Ah, thanks. I got confused by the DNS spoofing, but of course since the policy is protected by PKI TLS even if the attacker can redirect the MTA to evil.com/policy.txt the cert won't match, and the email recipient domain is already in the email to be delivered. (And if that can be spoofed, then the mail contents are also very likely accessible.)
I wanted to then follow up with an insightful or interesting comment but I am at a loss.
Are you sure you're not thinking of HPKP?
Essentially the problem with HSTS is it's a malicious choice to remove user agency because the spec intentionally prohibits web browsers from allowing a bypass option, despite the browser being an agent of the user, not the server. It also tells you to talk to your administrator, which is unhelpful when you are the administrator but the browser refuses to allow the administrator to continue.
Every time I've encountered HSTS in practice, it's been because of a perfectly normal certificate error I'm aware of the reason for (usually expiration) and have no real concerns about bypassing, except my own web browser won't let me.
The problem with HSTS (and MTA-STS) is that these are specs designed for internet centralization, where Google or Microsoft controls everything and manages everything[1], and a certificate never lapses. It's not designed for the real world, and neither of these specs would've made it except for that big tech has complete capture of web standards.
[1] Didn't know who the authors were when writing this comment, but the authors of the MTA-STS RFC are in fact, Google, Google, Microsoft, Comcast, and Yahoo.
HSTS would be an annoyance, but still manageable if not for the complete removal of our user agency. I think that's really where HSTS moves from a security specification to an abhorrent abuse of monopoly control of web standards. It's less about protecting the user and more about giving Google and such power over what you can and can't view with your browser.
For any other certificate issue, my browser will allow me to bypass it if I know what I am doing. But because HSTS has hijacked the browser, it will no longer act in my stead unless I fork the browser and recompile it. I consider HSTS to be a malicious specification in this respect.
HSTS by specification prohibits browsers from offering that option. So I can know a server is serving valid, authentic traffic via HTTPS, be aware of why the certificate has an issue, and HSTS requires that my browser prohibit me from connecting to the server.
Google can cut off your account on a whim with no recourse and God forbid you want to escape your isp but keep your email address with them!
In my case, I use Cloudflare for my domain so I set up a Cloudflare Pages project to generate and host the policy file at the mta-sts subdomain which is nice because I don't have to worry about hosting or SSL/TLS.
As long as your provider supports MTA-STS, you're only on the hook for setting up the records and hosting the policy file.
But if you ever decide to change your mail provider, you'll have to remember to correctly update your MTA-STS policy. If your change to Cloudflare Pages doesn't propagate through the Cloudflare CDN right away, you could end up in the situation described in the blog post, with the TXT record updated before the text file, and other mail servers unable to send you email.
Unless I'm mistaken in how this is implemented (not just server side)
Unless your provider provides MTA-STS endpoints that you can CNAME your _mta-sts and mta-sts subdomains to. I haven't seen anyone do this yet.