<div dir="ltr">On Mon, Nov 25, 2013 at 1:01 AM, ianG <span dir="ltr"><<a href="mailto:iang@iang.org" target="_blank">iang@iang.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
S/MIME failed because it is an atrocious key management design. Everything about it is designed to rely on certs, and nobody wanted to buy certs, and when you bought them, they didn't work well enough.  It's a CA's perfect protocol because it places the cert at the apex of the mission, and a user's nightmare because certs fail too frequently in the aggregate to avoid the curse of K6 -- turn it off, dump it.  In practical import (from actual experience), if you had a group of say 12 people with one year certificates, every month some person was failing to communicate because her cert had expired.... Do the math.<br>
</blockquote><div><br></div><div>The problem isn't the certificates, it is leaving the management to end users.</div><div><br></div><div>S/MIME was designed for enterprise use based on experience of the military email system. And as we know from Snowdonia, it did not even work there.</div>
<div><br></div><div>A while back Glen Greenwald and I caught Petraeus' PR guy, a Col. Boylan lying about having sent Greenwald an email. What happened was Boylan sent Greenwald an email which he promptly published, Boylan is a public official it is a public document. I then wrote to Boylan pointing out that if he was in the UK army rather than the US he would be court martialled for writing a letter like that. Boylan then wrote to me denying having sent the message, a lie quickly exposed by examining the sequence numbers in the headers. </div>
<div><br></div><div>The point here being that accountability is also important. If someone had been impersonating Boylan in that message it should have been a major concern. There should have been an enquiry because it is rather significant when the enemy might be injecting false communications as Boylan alleged.</div>
<div><br></div><div>If S/MIME worked right then all the messages would have been signed and Boylan would have known that he was always accountable for what he wrote.</div><div><br></div><div><br></div><div>But that said, the idea of authenticating the sender (i.e. the US military) is a good one. But the execution is pretty much <a href="http://healthcare.gov">healthcare.gov</a>. It is a boondoggle for contractors who are never held accountable for their stuff not really working right.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
PGP failed because it never succeeded in conquering the GUI clients. That was in part because of what PHB calls the Betamax-VHS war.  The providers of the major clients were already in the certificate camp, so they locked out the PGP side.  It was beyond the resources of the PGP group to crack that barrier.<br>
</blockquote><div><br></div><div>And the other part of the problem was that PGP does not meet the trust needs of the enterprises.</div><div><br></div><div>There just wasn't the perceived market demand to fix the system.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hence, I've concluded that email is unsecurable.  Obviously Jon and PHB and Ladar think differently.  I applaud their efforts and hope they prove me wrong.  But the lessons of Skype and Facebook and Netscape are writ very large -- great security achievements come from 3 party networks, not 4 party networks.<br>
</blockquote></div><div><br></div><div>I really think that Snowdonia has opened an opportunity here. I have a three phase plan</div><div><br></div><div>1) Use direct trust exchange (strong email addresses <fingerprint>?<a href="mailto:alice@example.com">alice@example.com</a>) to allow people to exchange secure mail with people they know using existing, unmodified mail clients without plug-ins and without maintenance.</div>
<div><br></div><div>2) Build out infrastructure to support other trust models including CA trust and peer-endorsements and trust discovery. Can now send email to people without knowing their trust credentials in advance.</div>
<div><br></div><div>3) Transition to mail clients with native support that also support a new messaging protocol that cleans up the insanities of SMTP and supports other modes (dropbox, chat, voice, video) and always goes over TLS.</div>
<div><br></div><div><br></div><div>We won't get to protect meta data properly till we get to step 3 but each step is manageable, has significant demand and builds out the infrastructure for the next step.</div><div><br>
</div><div><br></div><div>The technical hook is designed into step 1. The mechanism requires a mapping of the fingerprint to a key that is to be used to encrypt the email under. That mapping can be to a permanent signing key that signs limited lifespan encryption keys. The same mechanism can produce other signed statements such as to redirect the mail to another address or to use a particular format (PGP, SMIME) or a completely new protocol.</div>
<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>