A MITM could also deny SMTPS ports. If you want to ensure STARTTLS is in use then most smtp software has a setting to force STARTTLS or drop the connection.
My understanding that the issue is that attackers will then just do STARTTLS with their own self-signed certificate, as checking the common name of the certificate is difficult in the context of SMTP.
Well, use DNSSEC and add a new field in the DNS (e.g. CRYPTINFO = FORCE-HTTPS, FORCE-SMTPS). That would take time to spread, yes, but it would be a perfect solution for a lot of "prevent MITM downgrade" issues.
Yes, it would take a long time to spread considering there's a whopping 388 domains out there using DNSSSEC for SMTP, the majority of them run by neckbeards and not commerical email services.
388 Zones have deployed TLSA for SMTP with STARTTLS (Port 587)
What I'm saying is that there's no difference in STARTTLS and SMTPS. In either case, the client should drop the connection if it doesn't manage to negotiate the desired transport encryption.
Whether that happens because it doesn't get the expected response to STARTTLS or because the SMTPS port fails to respond with a proper TLS handshake is the same.
A "downgrade attack" only works if the client decides to keep going after failing to establish encryption. This is a client policy configuration issue, and has nothing to do with whether one uses the bytes "HELO server\r\nSTARTTLS\r\n" or a raw TLS handshake to negotiate the connection after opening the TCP port.
STARTTLS exists as an opportunistic encryption upgrade, not enforcement. If a MITM strips the advertisement of STARTTLS (very, very simple to do) the client and server will both happily continue plaintext communications.
This is the default for every mail server I've ever seen.
This is the default for every mail client I've ever seen.
How are people not terrified of this?
Mind you, this is literally what a Cisco PIX/ASA firewall does when you enable the "esmtp inspect" feature. It strips the STARTTLS so everyone falls back to plaintext and it can "scan" your email communications for Bad Things^TM.
When Cisco ASA is configured for ESMTP inspection, the ASA is not able to examine
the TLS session because it is encrypted. Therefore the ASA will prevent the
establishment of the STARTTLS session and allow the SMTP endpoints to determine
whether the SMTP session should continue in clear text (that is, with no privacy).
This is very normal. I can't remember the last time I encountered a small business with a Cisco PIX/ASA that didn't have this enabled.
Mandatory TLS encryption: announce STARTTLS support to remote SMTP clients,
and require that clients use TLS encryption. According to RFC 2487 this
MUST NOT be applied in case of a publicly-referenced SMTP server. Instead,
this option should be used only on dedicated servers.
You don't enforce STARTTLS receiver-side (smtpd). You enforce it sender-side (smtp) by looking up the receiver's policy using DNSSEC/DANE. This is allowed by the RFC and is implemented in Postfix. I've been running this on my personal mailservers for over a year.
All you need is a DNSSEC resolver and two lines of Postfix configuration to get it working:
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
It's configurable, as you say. Maybe I don't understand your argument "at least you won't be MITM'ed". Almost nobody runs SMTPS anyways. I'm just saying that if someone decides they want to enforce encrypted SMTP, it really doesn't matter if that is implemented as mandatory STARTSSL vs SMTPS. One is not more suspectible to MITM than the other.
