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.
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.
In recent years a few people (myself included) have tried again to inject the use of DNS service records into the HTTP/2 effort and have been consistently knocked back by the authors. Last I looked, the new standard was studiously burying its head in the sand and avoiding mentioning lower-layer resolution issues at all, as though things like dual-stack IP, port number variation or the zone-apex issue were Somebody Else's Problem. Whilst I think they are glaring UX issues for HTTP clients that arise directly from the continuing and mistaken default of resolving address records.
Of course what we get instead is unspecified and even conflicting* behaviour, which I think just stinks. Many other standards have managed to get it together by specifying the use of SRV. I gave up trying to change the entrenched positions.
* there is language in the draft that advises against multiple connections, conflicting with the current "Happy Eyeballs" dual-stack resolution workaround.
One reason DNSSEC is unpopular is that it fails to address the fact that centralized PKI suffers from tons of problems. Those problems would defeat the purpose of a gesture as serious as putting your gpg key in DNS.
It always seems ridiculous to me that people are coming up with ways to cope with universal CAs (Tack, Convergence, CRLSets, etc.), but can't imagine how to apply those same ideas with a hierarchical system.
CAs are a problem that DNSSEC doesn't solve, but DNSSEC solves tons of other problems without making the CA problem harder.
I think it's unpopular, because it is complex and it doesn't address privacy (between you and your ISP at least).
Centralized, hierarchical PKI is ok here, because it is better than what we have now (600 CAs for TLS, unsigned DNS, etc.) and nobody has a proposal for a fully decentralized system that ordinary people can understand (as demonstrated by GPG).
Sure but those are the same problems that a centralized domain name system suffers from. Currently, we have the privilege of paying for a second centralized system (CAs) which solves none of them.
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.
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?
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?
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.
You have it exactly backwards. If you are designing a new protocol, you do mandate encryption. Look at eg. recent new Web protocols, they all do it: WebRTC, WebSockets, SPDY.
Yes, the crypto engineering can be bewildering for non-experts, but it's just engineering at the end of the day.
In many cases there are defenses against downgrade attacks.
There is even hope for the web browsery scenario (have to be back compatible with SSL + connect to unknown/untrusted server, same as email): See http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv...
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.
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.
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?
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.
I know this because our SMTP gateway does exactly that, transparently with postfix.
Yes, the point about downgrades is moot when it comes to server-to-server SMTP, since downgrades have to be allowed to be interoperable.
The downgrade problem isn't moot with other protocols (like IMAP or client-to-server SMTP) which are virtually always expected to be secure. And the other points, about how STARTTLS adds complexity and prevents protocol-agnostic termination, still apply.
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?
It's not a protocol but an implementation problem.
Not just applications, servers as well. My Postfix/Dovecot setup does support unencrypted connections, but will refuse to do authentication if the channel is not encrypted.
Since it's just for backwards compatibility, modern clients should never drop to unencrypted communication. It's the server that needs to support older clients, not the other way around.
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.
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.
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.
I'm still worried that this adds too much false sense of security as it is right now.
There will always be misconfigurations, so we will always need ways to detect and handle them.
Encrypting everything everywhere increases the cost of snooping, which is good. It's a long way from perfect, but that shouldn't stop us from making an improvement.
To mitigate pervasive monitoring, new protocols should have only secure versions.
Isn't this the direction newer protocols are taking? AFAIK HTTP 2.0 is always encrypted (even if no SSL cert is installed)
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.
> Isn't this the direction newer protocols are taking? AFAIK HTTP 2.0 is always encrypted (even if no SSL cert is installed)
Using ad-hoc certificated is as safe as using STARTTLS: a MITM can just put his own cert (similar to a MITM removing the STARTTLS capability announcement from the client to the server). It's actually worse, since the client will think it's communication is safer than it actually is.
This is a matter of UI design, then. Eventually I'd expect secure sites to be the default (with broken lock symbols in the URL bar if not), with higher levels of security carrying something like the secure site symbols we see today.
Encryption and identity assurance are two different things - you can easily have the first which makes passive monitoring much more difficult without the trust infrastructure to mitigate MITMing.
For the average user, knowing what we know now, I'd say the first is a much more clear and present danger. The second requires a person to actually take interest in your traffic.
Comments
Port numbers are a limited resource.
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.
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.
In recent years a few people (myself included) have tried again to inject the use of DNS service records into the HTTP/2 effort and have been consistently knocked back by the authors. Last I looked, the new standard was studiously burying its head in the sand and avoiding mentioning lower-layer resolution issues at all, as though things like dual-stack IP, port number variation or the zone-apex issue were Somebody Else's Problem. Whilst I think they are glaring UX issues for HTTP clients that arise directly from the continuing and mistaken default of resolving address records.
Of course what we get instead is unspecified and even conflicting* behaviour, which I think just stinks. Many other standards have managed to get it together by specifying the use of SRV. I gave up trying to change the entrenched positions.
* there is language in the draft that advises against multiple connections, conflicting with the current "Happy Eyeballs" dual-stack resolution workaround.
One reason DNSSEC is unpopular is that it fails to address the fact that centralized PKI suffers from tons of problems. Those problems would defeat the purpose of a gesture as serious as putting your gpg key in DNS.
It always seems ridiculous to me that people are coming up with ways to cope with universal CAs (Tack, Convergence, CRLSets, etc.), but can't imagine how to apply those same ideas with a hierarchical system.
CAs are a problem that DNSSEC doesn't solve, but DNSSEC solves tons of other problems without making the CA problem harder.
I think it's unpopular, because it is complex and it doesn't address privacy (between you and your ISP at least).
Centralized, hierarchical PKI is ok here, because it is better than what we have now (600 CAs for TLS, unsigned DNS, etc.) and nobody has a proposal for a fully decentralized system that ordinary people can understand (as demonstrated by GPG).
Sure but those are the same problems that a centralized domain name system suffers from. Currently, we have the privilege of paying for a second centralized system (CAs) which solves none of them.
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.
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?
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?
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.
You have it exactly backwards. If you are designing a new protocol, you do mandate encryption. Look at eg. recent new Web protocols, they all do it: WebRTC, WebSockets, SPDY.
Yes, the crypto engineering can be bewildering for non-experts, but it's just engineering at the end of the day.
In many cases there are defenses against downgrade attacks. There is even hope for the web browsery scenario (have to be back compatible with SSL + connect to unknown/untrusted server, same as email): See http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv...
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.
IMAP and SMTP are not new, that's the point.
The context was "If you are starting a new protocol ..."
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.
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?
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.
I know this because our SMTP gateway does exactly that, transparently with postfix.
Yes, the point about downgrades is moot when it comes to server-to-server SMTP, since downgrades have to be allowed to be interoperable.
The downgrade problem isn't moot with other protocols (like IMAP or client-to-server SMTP) which are virtually always expected to be secure. And the other points, about how STARTTLS adds complexity and prevents protocol-agnostic termination, still apply.
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?
It's not a protocol but an implementation problem.
STARTTLS is and implementation of SSL/TLS protocol
Kudos for stating the obvious. Now how do we do something about this?
a poorly-programmed client would fall back to using the protocol without TLS
This is not a protocol vulnerability though. Poorly written programs cause problems with any protocol.
I think the implication is that the design of this protocol makes it much easier to get away with creating bad code, in comparison to the alternative.
That was the whole point of STARTTLS - to allow a way to start a tunnel but be backwards compatible to older clients.
The real problem was that they didn't account for MITM attacks.
Many applications that support STARTTLS can be configured to require a secure connection to be in place before sending any data.
Not just applications, servers as well. My Postfix/Dovecot setup does support unencrypted connections, but will refuse to do authentication if the channel is not encrypted.
Which is pointless when the plaintext password has already been sent across the wire.
Since it's just for backwards compatibility, modern clients should never drop to unencrypted communication. It's the server that needs to support older clients, not the other way around.
We wrote pretty much this years ago at FastMail:
https://www.fastmail.fm/help/technical/ssltlsstarttls.html
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.
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.
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.
I'm still worried that this adds too much false sense of security as it is right now.
There will always be misconfigurations, so we will always need ways to detect and handle them.
Encrypting everything everywhere increases the cost of snooping, which is good. It's a long way from perfect, but that shouldn't stop us from making an improvement.
You are not encrypting everything everywhere.
It is putting things in a different envelope for each hop you are doing in the post.
Yes, it is secured in transit, but there is no way that you can verify that everything went securely.
Sure. But the point stands: it makes snooping more expensive. Is it perfect? No. Is it better than nothing? Yes.
Isn't this the direction newer protocols are taking? AFAIK HTTP 2.0 is always encrypted (even if no SSL cert is installed)
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.
Using ad-hoc certificated is as safe as using STARTTLS: a MITM can just put his own cert (similar to a MITM removing the STARTTLS capability announcement from the client to the server). It's actually worse, since the client will think it's communication is safer than it actually is.
This is a matter of UI design, then. Eventually I'd expect secure sites to be the default (with broken lock symbols in the URL bar if not), with higher levels of security carrying something like the secure site symbols we see today.
Encryption and identity assurance are two different things - you can easily have the first which makes passive monitoring much more difficult without the trust infrastructure to mitigate MITMing.
For the average user, knowing what we know now, I'd say the first is a much more clear and present danger. The second requires a person to actually take interest in your traffic.
My understanding is that in HTTP/2.0 encryption will be optional. But that Chrome and Firefox at least will require it.
"Although it's trivial for a properly-programmed client to protect against this downgrade attack,..."
...that defeats the "use TLS when available" argument.