[146442] in cryptography@c2.net mail archive
[Cryptography] Separating concerns
daemon@ATHENA.MIT.EDU (Phill)
Wed Aug 28 13:10:10 2013
X-Original-To: cryptography@metzdowd.com
From: Phill <hallam@gmail.com>
In-Reply-To: <20130828085247.7ab75b0f@jabberwock.cb.piermont.com>
Date: Wed, 28 Aug 2013 10:15:38 -0400
To: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
My target audience, like Perry's is people who simply can't cope with anyth=
ing 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=85'
I also agree that the devil is in the deployment. And that is why I think w=
e need to separate concerns. We are not going to get anywhere if each and e=
very 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 i=
ns and other stuff for 50+ MUAs.
My experience of SET was that the scheme failed largely because it lacked a=
gility. The first draft of the protocol was to burdensome to use. But we co=
uld 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 depl=
oy 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. T=
he 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 pr=
oblem 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 forma=
t according to which has the larger installed base. S/MIME wins. End of sto=
ry. This does not mean committing to S/MIME PKI, or not supporting Web of T=
rust, 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 feedbac=
k as to why something can't be sent.
As it happens, I have been working on a protocol to provide exactly this de=
gree of separation. The idea being that the MUA makes a (secured) remote pr=
ocedure 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 trust=
ed service if the assertion of the trusted service is audit able and the MU=
A understands how to validate the assertion.
So here is how I would see it working, I have a scheme that combines elemen=
ts of Certificate Transparency with a meta-notary scheme I have been workin=
g 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 red=
uce the trust dependency on the broker by migrating some or all of the chec=
king into the MUA.
In practice it is likely that we would have omnibrokers that support more t=
han 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 li=
kely to want to combine ideas into a seventh rather than fight a VHS vs Bet=
amax.
In my particular scheme the omnibroker is a permanent fixture as my approac=
h is to attempt to mitigate the risks of using trusted third parties throug=
h separation of duties and multiple controls rather than eliminate them ent=
irely. But I think that people will still find a value in using my scheme a=
s a testbed even if they believe that the only acceptable approach is to el=
iminate 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 h=
ave a motive to facilitate deployment and spread it quicker. =
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
