[Cryptography] Separating concerns

[Phill]

My target audience, like Perry's is people who simply can't cope with anything more complex than an email address. For me secure mail has to look feel and smell exactly the same as current mail. The only difference being that sometime the secure mailer will say 'I can't contact that person securely right now because…'

I also agree that the devil is in the deployment. And that is why I think we need to separate concerns. We are not going to get anywhere if each and every one of us who has an idea has to implement an email client to make it work. And we certainly won't get any deployment if we have to deploy plug ins and other stuff for 50+ MUAs.

My experience of SET was that the scheme failed largely because it lacked agility. The first draft of the protocol was to burdensome to use. But we could not persuade banks who had paid $6 million to a vendor to deploy SETv1 to pay the same vendor another $6 million for the changes necessary to deploy a V2.

In the case of secure email there is an asymmetry. I think that deployed S/MIME has the problem of receiving and decrypting mail solved pretty well. The part that remains broken is establishing keys and sending the messages.



Which is why I think a critical step is to separate out the parts of the problem which can fixed for all proposals from the parts where innovation is possible.

I consider the following parts of the problem to be fixed:

1) Message formats: S/MIME

There is no intrinsic advantage to PGP or S/MIME format so choose one format according to which has the larger installed base. S/MIME wins. End of story. This does not mean committing to S/MIME PKI, or not supporting Web of Trust, but it does mean using CMS/PKCS#7 for message packaging.

2) MUA crypto User Interface: None

There must be no demand made of the user whatsoever. No button to press to send the message encrypted instead. The message is encrypted if the MUA can send it encrypted, end of story. 

The only UI that may be needed in the MUA would be to give the user feedback as to why something can't be sent.


As it happens, I have been working on a protocol to provide exactly this degree of separation. The idea being that the MUA makes a (secured) remote procedure call to a trusted service that tells it:

1) Whether the email should be sent encrypted
2) The crypto parameters (key, algorithm, etc,) to use if so
3) (optional) proof that allows the MUA to validate the action of the trusted service if the assertion of the trusted service is audit able and the MUA understands how to validate the assertion.


So here is how I would see it working, I have a scheme that combines elements of Certificate Transparency with a meta-notary scheme I have been working on. To implement this scheme I would write the necessary handlers for an omnibroker server to allow us to deploy the scheme and test it. If we find we need to tweak the scheme we tweak the omnibroker side of the scheme, the MUA side stays constant. If we think it is ready for prime time we can reduce the trust dependency on the broker by migrating some or all of the checking into the MUA.

In practice it is likely that we would have omnibrokers that support more than one scheme and in particular provide support for legacy schemes as well. If we have six schemes and three get some sort of traction then we are likely to want to combine ideas into a seventh rather than fight a VHS vs Betamax.


In my particular scheme the omnibroker is a permanent fixture as my approach is to attempt to mitigate the risks of using trusted third parties through separation of duties and multiple controls rather than eliminate them entirely. But I think that people will still find a value in using my scheme as a testbed even if they believe that the only acceptable approach is to eliminate the Trusted Third Parties entirely.

In practice the cost of crypto expertise is always going to exceed the cost of crypto products. I don't know what folk charge in the bargain basement for crypto clues but I rather doubt its less than my plumber. 

If someone can make a buck from a PRISM Proof email scheme then they will have a motive to facilitate deployment and spread it quicker.