ietf
[Top] [All Lists]

Re: Why are mail servers not also key servers?

2017-04-21 09:24:28
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.