I think people do understand your caveat, just that other concerns, such as providing actual security, override this. As the article argues, optional encryption does not work.
If you have authentication in the first version of your protocol, you can survive downgrade attacks by authenticating the version number.
For example, my email server will accept any email encrypted or not, but will only allow authentication over a channel if it's encrypted. But encryption is not optional for the latter case.
Email clients that attempt to authenticate won't send passwords over unencrypted plain-text connections, so there's no real vulnerability, unless a client is broken.
Sending the content of the email unencrypted is a pretty big vulnerability. Emails content is almost as sensitive as passwords and one would hope it would be systematically encrypted.
Comments
I think people do understand your caveat, just that other concerns, such as providing actual security, override this. As the article argues, optional encryption does not work.
If you have authentication in the first version of your protocol, you can survive downgrade attacks by authenticating the version number.
STARTTLS isn't just "optional encryption".
For example, my email server will accept any email encrypted or not, but will only allow authentication over a channel if it's encrypted. But encryption is not optional for the latter case.
Email clients that attempt to authenticate won't send passwords over unencrypted plain-text connections, so there's no real vulnerability, unless a client is broken.
Sending the content of the email unencrypted is a pretty big vulnerability. Emails content is almost as sensitive as passwords and one would hope it would be systematically encrypted.