The problem I keep seeing is that whenever we start talking about problem X, people immediately start throwing in problem Y, Z... Often prefixed with the words, 'but you obviously haven't thought about...'
I have identified at least a dozen problems with mail security, all of which need to be fixed in order to deploy something better. And I think I have a pretty good solution to all of them. I am not saying I have the best solution or a perfect solution but I have *A* solution.
Tweaking the SMTP mail infrastructure doesn't help because the sending and receiving device do not interact with either server directly under the current model. SMTP email has grown to meet a lot of important requirements in ways that make repurposing SMTP mail servers a non starter.
Talking about 'end to end' is also unhelpful because the only ends that matter are the sender and receiver brains and you are not going to have true end-to-end in out lifetime. The last and the first meter is always going to be a weak link. As I showed in another post, there are good reasons to only accept encrypted messages end-to-end after the sender has been deemed trustworthy.
Also, Dave Crocker will soon chime in to point out the deployment problem. And he is completely right. You are not going to replace SMTP with a new email system. The only way that a system as pervasive as SMTP has ever been replaced is by a new system that offers a superset of its functions.
I watched Tim B-L very carefully at CERN and I think I learned how the deployment strategy of the Web worked. The key was to find one feature that the Web offered to a distinct community that nothing else provided. In this case the feature was to allow people to read the CERN phone book without using CERN-VM, a mainframe whose operating system was the most unpleasant in history.
So the first step towards sanity is to talk about data level security, not just message. Right now, there is no standards based approach to encrypting business documents, Word, Excel, program code, etc. in ways that support business processes. Yes, you can buy and configure a Microsoft CRM system but it only works for Microsoft products and not even the CIA and NSA bother with it, hence Snowden, Manning and the two as yet unknown GRU moles in NSA and CIA who supplied the Shadowbroker and Vault7 data.
The principle obstacle to deployment of such a system has been a set of patents on the core technology. Patents which expire this year.
A secondary obstacle has been the insistence on perfect security so that if Alice sends a document to Bob, Bob can only use it for purposes Bob approves of. That might sound good till you realize it makes the document next to useless to Bob. He can't edit, can't steal slides from a Powerpoint Deck, he can't even show it without permission. Oh and he can only use particular hardware configurations.
The biggest pratfall for traditional CRM schemes is that most of the most important documents in any corporation have to be sent outside the company. We are required to open our accounts to our auditors, we are required to share trade secrets with our external counsel to apply for patents and of course we have to share price information with customers to make a sale.
So what I suggest we do is that we start a Working Group to develop a Confidential Document Control protocol, that is CRM minus the secure hardware requirement.
Proxy Re-Encryption provides the technical capabilities we need to meet the requirements of CDC. We would of course need to also solve the key distribution problem. I have running code which addresses both.
Note however that once you solve the key distribution problem for CDC, you can apply that solution to SSH, Web password management, second factor authentication/confirmation and yes, messaging.