<i>Port numbers are a limited resource.</i><p>That's actually a pretty good point and I wish more services used SRV records to determine which host and port to use. HTTP 2.0 was a chance to implement it for HTTP but the effort fizzled out after just a handful of comments in 2007 or so.<p>I also like the idea of squeezing other information into DNS, like certificates, gpg keys, why not HSTS-like
information too? Say, a TXT record enforcing ssl, no exceptions (ssl=all). But all this hinges on DNSSEC which is very unpopular here.
I think people do not understand that the statement "you should always and only use encryption" is seriously flawed when it comes to protocols used by millions of applications.<p>If you are starting a new protocol for a wide audience you cannot just say "encryption is required". Which encryption protocol will you require? And will you stick with it forever? Even when it will be broken?<p>So you want a bit of forward compatibility and you add a version identifier to wire protocol the or some other form of negotiation. Well done, now you are opening your self to protocol downgrade attacks. You can try to fight this as much as you want, but will always be back to square one: support for non-updated applications: drop them or support them even thou you know there is a security problem in supporting them?<p>All the non-public SMTP servers I have used in the last years require the use of STARTTLS-enabled connections. So they are dropping old clients, but they can do that because they have a tight control over the "environment" (their students, their employers, etc). Others do not have this luxury.
Considering every damn SMTP server out there that talks STARTTLS actually just accepts any certificate by default including self-signed ones, isn't this entire point moot?<p>It prevents casual attackers watching the wire i.e. network taps but doesn't prevent MITM at all as you can just proxy it with another self signed cert and it goes through.<p>I know this because our SMTP gateway does exactly that, transparently with postfix.
<i>a poorly-programmed client would fall back to using the protocol without TLS</i><p>This is not a protocol vulnerability though. Poorly written programs cause problems with any protocol.
> a poorly-programmed client would fall back to using the protocol without TLS<p>That was the whole point of STARTTLS - to allow a way to start a tunnel but be backwards compatible to older clients.<p>The real problem was that they didn't account for MITM attacks.
We wrote pretty much this years ago at FastMail:<p><a href="https://www.fastmail.fm/help/technical/ssltlsstarttls.html" rel="nofollow">https://www.fastmail.fm/help/technical/ssltlsstarttls.html</a><p>All the downgrade and pre-encryption MITM and complexity arguments are definitely worth repeating though. Straight up SSL is significantly better.
Opportunistic encryption between endpoints doesn't necessarily require STARTTLS. That is merely a current convention. It could change in future, with the development or invention of some new crypto paradigm. Case in point: opportunistic IPSEC. Okay that wasn't the answer either, but it is an alternative in principle, albeit not in practice today for global SMTP.<p>Point is, I think it's naive and unwise to assume that the crypto upgrade/wrapper is and always shall be TLS and then to build this assumption into standards in a manner that isn't future compatible. We are due a great many innovations in end-to-end crypto over the next few decades. For example, I'm hoping that new and interesting uses will be found for DANE. Maybe we can even bring back network-layer opportunistic encryption.
I am still not convinced by the "encrypt all the SMTP traffic" argument. It adds more encrypted traffic, but these mails are still decrypted on the mail servers to inspect them and then to forward them again.<p>Worse still, most mail servers and programs have no checks whatsoever regarding certificates of other mail servers or clients. As long as it is able to crypt and decrypt, it's acceptable. If you're lucky there is some sensible admin who restricts algorithms.<p>I'm still worried that this adds too much false sense of security as it is right now.
> To mitigate pervasive monitoring, new protocols should have only secure versions.<p>Isn't this the direction newer protocols are taking? AFAIK HTTP 2.0 is always encrypted (even if no SSL cert is installed)<p>For the mentioned protocols: most IMAP and SMTP servers (which enable TLS) disregard the IETF and allow TLS-on-connect connections on ports 993 and 465 respectively. If the IETF would (again) standardize this the problem would be reasonably solved.
"Although it's trivial for a properly-programmed client to protect against this downgrade attack,..."<p>...that defeats the "use TLS when available" argument.