[Cryptography] PRISM PROOF Email

Carl Ellison cme at acm.org
Fri Aug 23 12:38:21 EDT 2013


Ease of use implies ubiquitous deployment. Seeing how hard it was to get that in mail clients I'm not sanguine. Then there's the move to web mail. Clients with keys may be a thing of the past but keys in web servers are subject to national security letters. 

Meanwhile PRISM was more about metadata than content, right? How are we going to prevent traffic analysis worldwide?

Carl


Sent from my phone


On Aug 22, 2013, at 2:36 AM, Phillip Hallam-Baker <hallam at gmail.com> wrote:

> 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/
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20130823/c89ac312/attachment.html>


More information about the cryptography mailing list