
<html><head></head><body>Let me just see if I get where you're going:<br>

<br>

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.<br>

<br>

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.<br>

<br>

One other question: PPE = Prism Proof Email?<br>

<br>

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

<br>

Philip Whitehouse<br>

<br><br><div class="gmail_quote">Phillip Hallam-Baker <hallam@gmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div dir="ltr">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.<div>

<br /></div><div>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.</div>

<div><br /></div><div><br /></div><div>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. </div><div><br /></div><div>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.</div>

<div><br /></div><div><br /></div><div>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. </div>

<div><br /></div><div>End to end has an unfortunate effect on usability as well. </div><div><br /></div><div><br /></div><div>My solution is to combine my 'Omnibroker' proposal currently an internet draft and Ben Laurie's Certificate Transparency concept. </div>

<div><br /></div><div>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'. </div>

<div><br /></div><div><a href="http://datatracker.ietf.org/doc/draft-hallambaker-omnibroker/">http://datatracker.ietf.org/doc/draft-hallambaker-omnibroker/</a><br /></div><div><br /></div><div><br /></div><div>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).</div>

<div><br /></div><div><br /></div><div>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.</div><div><br /></div><div>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 <a href="http://x.com">x.com</a> must be encrypted'.</div>

<div><br /></div><div>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.</div>

<div><br /></div><div><br /></div><div>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.</div>

<div><br /></div><div>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).</div><div><div><br clear="all" /><div><br /></div></div></div></div></blockquote></div><br>

-- <br>

Sent from my Android phone with K-9 Mail. Please excuse my brevity.</body></html>