[Cryptography] PRISM PROOF Email

Phillip Hallam-Baker hallam at gmail.com
Thu Aug 22 05:36:48 EDT 2013


Thanks to Snowden we now have a new term of art 'Prism-Proof', i.e. a
security scheme that is proof against state interception. Having had an
attack by the Iranians, I am not just worried about US interception.
Chinese and Russian intercepts should also be a concern.

We have two end to end security solutions yet Snowden used neither. If PGP
and S/MIME are too hard to use for the likes of Snowden, they are too hard
to use. The problem Snowden faced was that even if he could grok PGP, the
people sending him emails probably couldn't.


So to be properly PRISM-Proof an email security solution must be both proof
against state interception and easy enough to use that it can build
critical mass.

By easy enough to use, I mean 'absolutely no additional effort to
installation of an email client'. Everything has to be transparent to the
end user who is not a crypto expert and may well be a bit of a doof.


The traditional approach to making a system intercept proof is to eliminate
the intermediaries. PGP attempts to eliminate the CA but it has the
unfortunate effect on scalability. Due to the Moore bound on a minimum
diameter graph, it is only possible to have large graphs with a small
diameter if you have nodes of high degree. If every PGP key signer signs
ten other people then we have to trust key chains of 6 steps to support
even a million users and nine to support a global solution of a billion
users.

End to end has an unfortunate effect on usability as well.


My solution is to combine my 'Omnibroker' proposal currently an internet
draft and Ben Laurie's Certificate Transparency concept.

Omnibroker introduces a trust agent for the relying party to match the
trust agent for the key holder (the CA). So rather than have the usual
problem of the CA being selected by one side but delivering trust to the
other, each side in the transaction has 'representation'.

http://datatracker.ietf.org/doc/draft-hallambaker-omnibroker/


Since email is an asynchronous protocol there is no reason not to check for
CT proofs everywhere we can. But the omnibroker selected by a user has the
primary responsibility for keeping them safe. This means finding an
encryption key for the intended recipient of an email and verifying it, if
this is possible. If not, the broker returns evidence to the contrary (if
this is possible).


So the way this would work is that to use the system you would either
install a PPE aware email client or a pair of SMTP/IMAP proxies that are
PPE aware.

Whenever an email is sent the PPE client queries its local cache and the
omnibroker to determine if there is an encryption key on file for it. If
so, the email will be sent encrypted. The PPE client could in theory access
any key store including existing PGP key stores. It can also implement
rules like 'email sent to x.com must be encrypted'.

I believe that the user interface can be made essentially zero effort. If
the installer for a proxy set knows how the email app stores the
configuration data for mail servers, it can even rewrite these
automatically.


Preventing key substitution will require a combination of the CT ideas
proposed by Ben Laurie (so catenate proof notaries etc) and some form of
'no key exists' demonstration.

For spam control reasons, every email sent has to be authenticated which
means using digital signatures on the message (and likely DKIM + SSL client
auth).


-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20130822/6a9b082d/attachment.html>


More information about the cryptography mailing list