5 ms·

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 protocol

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.

jsiepkes 8y ago
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.
- btown 8y ago
  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 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/ https://hstspreload.org/ . And all the criticisms of a preload list apply here. Still, this is much better than nothing.
- stonogo 8y ago
  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.
  - tptacek 8y ago
    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.
    - stonogo 8y ago
      > 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.
  - geofft 8y ago
    > "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.
    - stonogo 8y ago
      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.
shereadsthenews 8y ago
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%.
- uiri 8y ago
  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.
  - tptacek 8y ago
    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.
  - phicoh 8y ago
    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.
tptacek 8y ago
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".
- blitmap 8y ago
  Google is in a position where they could have disallowed protocol downgrades, setting a standard without defining a standard.
  - netheril96 8y ago
    Ha, imagine the outcry in that case. It certainly would be even louder than this one.
- kortilla 8y ago
  Is this work important because it displaces DNSSEC or because it’s the right solution?
  - tptacek 8y ago
    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.
- stonogo 8y ago
  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.

jsiepkes 8y ago

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.

btown 8y ago
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 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/ https://hstspreload.org/ . And all the criticisms of a preload list apply here. Still, this is much better than nothing.
stonogo 8y ago
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.
- tptacek 8y ago
  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.
  - stonogo 8y ago
    > 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.
- geofft 8y ago
  > "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.
  - stonogo 8y ago
    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.

shereadsthenews 8y ago

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%.

uiri 8y ago
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.
- tptacek 8y ago
  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.
- phicoh 8y ago
  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.

tptacek 8y ago

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".

blitmap 8y ago
Google is in a position where they could have disallowed protocol downgrades, setting a standard without defining a standard.
- netheril96 8y ago
  Ha, imagine the outcry in that case. It certainly would be even louder than this one.
kortilla 8y ago
Is this work important because it displaces DNSSEC or because it’s the right solution?
- tptacek 8y ago
  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.
stonogo 8y ago
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.