> In other words, the bugs are in faulty implementations, not specification. Problems with STARTTLS have been going on for atleast a decade. At some point you

> In other words, the bugs are in faulty implementations, not specification. Problems with STARTTLS have been going on for atleast a decade. At some point you need to start wondering if the design isn't the problem. Besides, why would you even want STARTTLS? Even the authors of the RFC can't come up with a good reason to use STARTTLS [1]. Most of these reasons are from another era: > Separate ports lead to a separate URL scheme which intrudes into the user interface in inappropriate ways. Actually knowing in advance if something is going to be a secure connection (like HTTP vs HTTPS) sounds pretty desirable to me. > Separate ports imply a model of either "secure" or "not secure." This can be misleading in a number of ways. First, the "secure" port may not in fact be acceptably secure as an export-crippled cipher suite might be in use. This can mislead users into a false sense of security. Second, the normal port might in fact be secured by using a SASL mechanism which includes a security layer. Export ciphers are obviously not a thing in 2024 anymore. And "using a SASL mechanism which includes a security layer" where apparently someone made their own alternative to TLS sounds like a really bad idea. > Use of separate ports for SSL has caused clients to implement only two security policies: use SSL or don't use SSL. That actually sounds desirable. > Port numbers are a limited resource. While they are not yet in short supply Only very few protocols get an actual IANA assigned port number nowadays. [1] https://datatracker.ietf.org/doc/html/rfc2595#section-7 https://datatracker.ietf.org/doc/html/rfc2595#section-7