[Cryptography] PRISM PROOF Email

[Philip Whitehouse]

Let me just see if I get where you're going:

So essentially you've increased the number of CAs to the number of companies without really solving the PRISM problem. The sheer number mean it's impractical to do much more than a cursory check before approval.

PRISM for email is bad because we don't even know who we can trust. I can't trust the provider because they could have been served an NSL. The provider has to see the metadata or they can't route the email. So I'm doomed. Best case is I can secure the contents and use an alternate name. At that point I need an organization I trust to act as my Omnibroker who for some reason I don't trust with the mail itself.

One other question: PPE = Prism Proof Email?

Nor do I think key chain length was the problem - initial key authentication and distribution is the first issue.

Philip Whitehouse


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

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20130823/3c905fdb/attachment.html>