There's nothing lowbrow about it; it's a technical objection to the protocol and a commentary on Google's socialization of a bad idea. I'll thank you to focus on the merits of the argument instead of trying to besmirch its character.
There is nothing untenable about "the situation," because the attack you suggest has never been spotted in the wild, targets one of the less-weak links in the SMTP chain (i.e. there is lower-hanging fruit), and finally comprise a false dichotomy between "MTS-STA" and "do nothing."
All MTA-STS requires is effectively fetching a domain name and port number over HTTPS, then DNS query as usual and connect to the port. Literally nothing is gained over simply securing the MX record delivery to start with, to the degree that when someone brought this up on the IEFT draft process the response was nontechnical -- "we think people already have an https endpoint" is not how you design a standard.
DANE exists, is only onerous to learn one time, and 'world governments' are how humanity operates, in case you haven't noticed. The fact that we currently have a global PKI rooted in huge corporations is not sustainable if you want an Internet that human beings are allowed to participate in. I acknowledge that this may be a fundamental disagreement in worldviews, but your preference for corporate rule over government rule is not the correct category of consideration for standards development.
There has not in fact been an SMTP-over-TLS port "for ages." There is not one now. There is a submission-over-TLS port for MUAs, and there is STARTTLS on port 25, but there is not an MTA-related SMTP-over-TLS port specified in any standard. STARTTLS is idiocy for obvious reasons beyond aesthetic layer violations, but the MTA-STS people declined to address in a technical manner their lack of support for SMTP-over-TLS port standardization, providing instead a set of assumptions about what other people might or might not know. Again, terrible. And again, exactly your argument here.
MITM attackers can RST connections to MTA-STS-specified ports just as well, and I question your implied assumption that MTA-STS somehow protects against this: it does not.
MTA-STS does not explicitly require every message to do anything; it requires MTAs to do all this legwork, and less wealthy operators can just pay for the bandwidth, right? Transport is free, of course -- at least if you were on the MTA-STS design committee.
Basically, every single defense of "MTA-STS" as a solution rests in the root of "we think fixing DNS is hard" and that is exactly the failure of vision I spoke about earlier. You've consistently expressed this view and I do not expect that you'll change your opinion, but copping out because things might be difficult is the wrong answer. Letting megacorps drive standards processes, rejecting every single attempt to collaborate that came from outside the ivory tower, and then telling us it's for our own good (because our poor little low-brow brains can't possibly fathom how nameservices work) is terrible, terrible policy.
MTA-STS is a failure of vision, a failure of process, and a failure of our industry. In the long run, it's a minor one, but it so purely and cleanly exemplifies the root causes of the de-democratization of the Internet that I feel strongly about calling it out as the failure it is.
I'm actually confused here. Stonogo is using enough detail that they sound like someone who understands the domain, but what they're saying is, in many cases, simply factually incorrect.
A few corrections:
1. MTA-STS does not specify ports. I don't even know where that comes from. Mail continues to be sent on port 25.
2. The claim that "nothing is gained over security the MX record to start with" is, again, simply untrue. DNSSEC alone does not solve anything, unless you also somehow validate the presented identity of the recipient MX--which is what DANE and MTA-STS attempt to provide. DANE arguably does this better (neglecting for now the debates about roots of trust and DNSSEC), but, to be perfectly clear, DNSSEC alone (or anything else that merely secures the MX record) does nothing to validate the recipient MX's identity (meaning you're vulnerable to e.g. BGP routing interception or other active MITM).
3. MITM attackers cannot merely RST connections to STS-specified ports. Among other reasons, because STS doesn't specify ports (meaning this criticism is nonsensical) but, assuming "ports" was supposed to read "hosts", because STS requires senders to validate the host's presented certificate. That's sort of the point of that.
I think the criticism here was written by someone who knows a lot of the context but seems not to understand the threat model. If you don't understand the threat model, yes, STS is going to look crazy.
I don't love MTA-STS. It's an imperfect compromise, which is sort of the nature of compromises. Stonogo does fairly contrast it with two alternative approaches: DANE (not just DNSSEC) and simply announcing a planned deprecation of unauthenticated SMTP (which, as an aside, would also require some currently-nonexistent principles on MX presented identities, like that the identity must match the @hostname of the destination mailbox--a constraint currently commonly violated).
But it's trying to solve an actual problem. And, as I said, the heart of the criticism here is simply factually incorrect, whatever warts STS does indeed have.
There is nothing untenable about "the situation," because the attack you suggest has never been spotted in the wild, targets one of the less-weak links in the SMTP chain (i.e. there is lower-hanging fruit), and finally comprise a false dichotomy between "MTS-STA" and "do nothing."
All MTA-STS requires is effectively fetching a domain name and port number over HTTPS, then DNS query as usual and connect to the port. Literally nothing is gained over simply securing the MX record delivery to start with, to the degree that when someone brought this up on the IEFT draft process the response was nontechnical -- "we think people already have an https endpoint" is not how you design a standard.
DANE exists, is only onerous to learn one time, and 'world governments' are how humanity operates, in case you haven't noticed. The fact that we currently have a global PKI rooted in huge corporations is not sustainable if you want an Internet that human beings are allowed to participate in. I acknowledge that this may be a fundamental disagreement in worldviews, but your preference for corporate rule over government rule is not the correct category of consideration for standards development.
There has not in fact been an SMTP-over-TLS port "for ages." There is not one now. There is a submission-over-TLS port for MUAs, and there is STARTTLS on port 25, but there is not an MTA-related SMTP-over-TLS port specified in any standard. STARTTLS is idiocy for obvious reasons beyond aesthetic layer violations, but the MTA-STS people declined to address in a technical manner their lack of support for SMTP-over-TLS port standardization, providing instead a set of assumptions about what other people might or might not know. Again, terrible. And again, exactly your argument here.
MITM attackers can RST connections to MTA-STS-specified ports just as well, and I question your implied assumption that MTA-STS somehow protects against this: it does not.
MTA-STS does not explicitly require every message to do anything; it requires MTAs to do all this legwork, and less wealthy operators can just pay for the bandwidth, right? Transport is free, of course -- at least if you were on the MTA-STS design committee.
Basically, every single defense of "MTA-STS" as a solution rests in the root of "we think fixing DNS is hard" and that is exactly the failure of vision I spoke about earlier. You've consistently expressed this view and I do not expect that you'll change your opinion, but copping out because things might be difficult is the wrong answer. Letting megacorps drive standards processes, rejecting every single attempt to collaborate that came from outside the ivory tower, and then telling us it's for our own good (because our poor little low-brow brains can't possibly fathom how nameservices work) is terrible, terrible policy.
MTA-STS is a failure of vision, a failure of process, and a failure of our industry. In the long run, it's a minor one, but it so purely and cleanly exemplifies the root causes of the de-democratization of the Internet that I feel strongly about calling it out as the failure it is.