My idea is that mandating encryption and allowing version/cipher negotiation are more or less the same thing. They are not the same thing, but they lead to similar conclusions.
What should be the response of a client when a server tells it during the cipher negotiation that the only cipher that it (the server) can use are those considered insecure by client?
Should the client proceed for the sake of interoperability? Or should the client raise and error and say "sorry, no secure connection can be established"?
Whatever you answer to that question is, why doesn't it apply to STARTTLS As well? By not allowing STARTTLS, the server has negotiated a set of cipher (i.e. {NULL-ENC}) that the client considers insecure. What should the client do? Close the connection? (You can configure your program to do so right now.) Or continue because you really want to send that email? (This is, sadly, the current configuration of many applications.)
Back to the original point, I think that the important thing here is not only to embed secure layers in protocols, but also (and mainly) to convince the users that it is OK for an application to answer "Sorry, no secure connection is available. Yes, I could set up an insecure connection, but I will not do that."
What should be the response of a client when a server tells it during the cipher negotiation that the only cipher that it (the server) can use are those considered insecure by client?
Should the client proceed for the sake of interoperability? Or should the client raise and error and say "sorry, no secure connection can be established"?
These are solved problems though; it's not as though this is a new consideration. This has been a 'problem' since SSL's implementation. If you can't agree on a cipher spec, you don't connect.
The issue with your argument in particular is that you're basically saying 'we shouldn't require encryption because it's too complicated to make a few choices', which implies to me that you think not using encryption is a better choice (since any TLS implementation requires these issues). Your argument, then, is an argument against SSL/TLS encryption in any respect, as opposed to mandatory encryption.
Back to the original point, I think that the important thing here is not only to embed secure layers in protocols, but also (and mainly) to convince the users that it is OK for an application to answer "Sorry, no secure connection is available. Yes, I could set up an insecure connection, but I will not do that."
This is pretty common; in fact, most software will just say that it can't connect, with no more detailed explanation unless you dig into it. I've also had issues where the default configuration for postfix on Ubuntu (STARTLS enabled, self-signed certificate) is rejected by some clients, requiring me to disable authentication on those clients (which required a secure connection) and whitelist their IP addresses (insecure!).
Two rounds of negotiation means two points of failure. TLS already has a version/cipher negotiation step; it's built into the protocol, and your library code will contain an implementation, where it can be audited. Duplicating that functionality per-protocol is dumb.
Comments
My idea is that mandating encryption and allowing version/cipher negotiation are more or less the same thing. They are not the same thing, but they lead to similar conclusions.
What should be the response of a client when a server tells it during the cipher negotiation that the only cipher that it (the server) can use are those considered insecure by client?
Should the client proceed for the sake of interoperability? Or should the client raise and error and say "sorry, no secure connection can be established"?
Whatever you answer to that question is, why doesn't it apply to STARTTLS As well? By not allowing STARTTLS, the server has negotiated a set of cipher (i.e. {NULL-ENC}) that the client considers insecure. What should the client do? Close the connection? (You can configure your program to do so right now.) Or continue because you really want to send that email? (This is, sadly, the current configuration of many applications.)
Back to the original point, I think that the important thing here is not only to embed secure layers in protocols, but also (and mainly) to convince the users that it is OK for an application to answer "Sorry, no secure connection is available. Yes, I could set up an insecure connection, but I will not do that."
What should be the response of a client when a server tells it during the cipher negotiation that the only cipher that it (the server) can use are those considered insecure by client?
Should the client proceed for the sake of interoperability? Or should the client raise and error and say "sorry, no secure connection can be established"?
These are solved problems though; it's not as though this is a new consideration. This has been a 'problem' since SSL's implementation. If you can't agree on a cipher spec, you don't connect.
The issue with your argument in particular is that you're basically saying 'we shouldn't require encryption because it's too complicated to make a few choices', which implies to me that you think not using encryption is a better choice (since any TLS implementation requires these issues). Your argument, then, is an argument against SSL/TLS encryption in any respect, as opposed to mandatory encryption.
Back to the original point, I think that the important thing here is not only to embed secure layers in protocols, but also (and mainly) to convince the users that it is OK for an application to answer "Sorry, no secure connection is available. Yes, I could set up an insecure connection, but I will not do that."
This is pretty common; in fact, most software will just say that it can't connect, with no more detailed explanation unless you dig into it. I've also had issues where the default configuration for postfix on Ubuntu (STARTLS enabled, self-signed certificate) is rejected by some clients, requiring me to disable authentication on those clients (which required a secure connection) and whitelist their IP addresses (insecure!).
Two rounds of negotiation means two points of failure. TLS already has a version/cipher negotiation step; it's built into the protocol, and your library code will contain an implementation, where it can be audited. Duplicating that functionality per-protocol is dumb.