Hacker News Reader

Comment by stonogo | Hacker News Reader

This article is a disingenuous description of a lot of bad work. A more honest headline would be "Google making email more complex by introducing more protocols." Instead of just registering an SMTP-over-TLS port, now EVERY message requires an HTTPS lookup and a reconnection. That's not the intent, but the specification was so poorly written that it is the most common interpretation.

All of the input during the IETF draft phase was completely disregarded unless it came from a sponsoring corporation (all of whom are either Google or residential ISPs). This whole process is a shameful illustration of IETF process failure and I hope Google terminates it as readily as they do business units.

View on HN

This comment is a lowbrow dismissal of important work. In the MTA-STS status quo ante, an attacker could break TLS and MITM SMTP transactions by forcing a protocol downgrade. That's an untenable situation, as would be a decree from the major mail providers that all mail must now be sent over TLS. The third alternative, widespread deployment of DANE, would be even more onerous for site operators, in addition to its unfortunate side effect of instituting a global PKI rooted in world governments.

There has been an SMTP-over-TLS port for ages. Obviously, that doesn't fix the problem, because a MITM attacker can simply RST connections to that port.

MTA-STS does not in fact require EVERY message to do an "HTTPS lookup and a reconnection".

Google is in a position where they could have disallowed protocol downgrades, setting a standard without defining a standard.

Ha, imagine the outcry in that case. It certainly would be even louder than this one.

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 revise my criticism. What you're saying is (broadly) wrong, but it is not lowbrow. I apologize for the knee-jerk reaction.

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.

Is this work important because it displaces DNSSEC or because it’s the right solution?

It's important to me because it displaces DNSSEC, but it's important to everyone else because it cleanly and quickly breaks an attack that people were worried about without boiling the ocean or requiring universal deployment of some new goo. I am not especially worried about the attack it breaks, because I don't believe in SMTP security in the first place. But it is a sensible way to address that attack.

Using an TLS only port doesn't solve the problem. Since MTA's will be required to also offer the normal unencrypted interface there would still be no way to tell an other MTA that it should use TLS with you. An mitm attack can then simply block access to your dedicated TLS port and force use of unencrypted protocols.

This is the same for-me-but-not-for-thee response the ISPs gave during the draft spec. Assign a TLS port, deprecate the plaintext port, and set a date when unencrypted SMTP is noncompliant. It really can be that simple, especially in an environment where Google has already demonstrated a willingness to manipulate the standards process for its own purposes.

The reason HTTPS is being forced into this process is exactly because HTTPS has a specified standard TLS-only port. Now we're married to a web protocol to send email, and the entire broken commercial web-of-trust hegemony is trickling into email as well. Google already has an outsized influence on which certificates may be trusted, and now that influence extends to email, de jure as well as de facto.

This is fragile, needlessly complex design, and it's depressing as hell to see it so thoroughly defended by people championing hypotheticals.

The fact that the argument for MTA-STS boils down to "DNS is insecure and we don't want to fix that problem" and the solution boils down to "just do everything over port 443 instead" indicates a severe failure of vision at every phase of this process.

In addition to the fact that, had Google declared plaintext SMTP EOL'd, someone else would be here to tell us how that too was an instance of Google ignoring the operator and standards community, and the fact that there's no real effort in the IETF to formally end plaintext SMTP, there's the fact that simply refusing to interop with plaintext SMTP wouldn't actually fix the problem; it would just break SMTP into a bunch of incompatible islands, which is run by a myriad of different users who are not, for a myriad of reasons, in a position to upgrade their software stack to TLS.

> different users who are not, for a myriad of reasons, in a position to upgrade their software stack to TLS.

These people, who I am not convinced exist in 2019, would also be left behind by MTA-STS, which still requires participation in the commercial PKI pyramid of trust, TLS connections and all. What makes you think an entity that cannot tls-wrap their mail service can instead rewrite the mail service to issue web requests, parse the responses, and then reconfigure their MTA on the fly for each response?

Deprecating plaintext messaging is a perfectly achievable goal, and there's no real effort in the IETF to do so because every such effort is drowned at birth by the bizarre "just do everything over HTTPS" phalanxes.

> "DNS is insecure and we don't want to fix that problem"

This isn't an accurate description of the anti-DNSSEC worldview. It's "DNS is untrusted, this is not a problem, and we want to keep it that way." If you're going to argue against it I think you need to portray the opposing side accurately.

I'm not describing a worldview; I'm describing the actual responses from the MTA-STS team during the IETF draft process. They did not say they wanted to keep DNS untrusted, they said that they did not think network operators were capable of understanding DNS security, and so the MTA-STS chose a different approach to securing SMTP.

Yep - this spec outlines exactly how to tell another compliant MTA that it should use TLS with you, and how to detect (on subsequent connections) this type of MITM. https://tools.ietf.org/html/rfc8461#section-10 explains the threat model.

Of course, to thwart an MITM of an initial connection, you'd need something like https://hstspreload.org/ . And all the criticisms of a preload list apply here. Still, this is much better than nothing.

STS is built around cached policies. It does not require an HTTPS transaction per message. Since a very high fraction of all email is sent between the sponsoring organizations (Google, Yahoo, Microsoft, and the ISPs you mentioned) it is likely that the aggregate cache hit rate will be approximately 100%.

If so much mail is sent between the sponsoring organisations that the aggregate hit rate will be approximately 100%, then wouldn't approximately 100% of mail be sent over the TLS only port were the sponsoring organisations to decide to only use TLS among themselves (e.g. a hardcoded SMTPS everywhere list) ?

The point of an open standard is so that the vanishingly small fraction of people running their own mail servers can easily implement it too.

Yes, this is an instance where the giant email providers could simply have agreed among themselves not to allow SMTP TLS MITM attackers, and then left everyone to fend for themselves.

Maybe it is just me, but I get mail from lots of small organisations. Maybe the bulk volume of mail is handled by a few parties, but if I look at all mail I care about, there are lots of parties.

Reply on news.ycombinator.com