3 ms·

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 tel

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.

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.