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