[148247] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: [Cryptography] Email is unsecurable

daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Mon Nov 25 16:57:56 2013

X-Original-To: cryptography@metzdowd.com
In-Reply-To: <5292E7BB.20601@iang.org>
Date: Mon, 25 Nov 2013 10:15:58 -0500
From: Phillip Hallam-Baker <hallam@gmail.com>
To: ianG <iang@iang.org>
Cc: Cryptography <cryptography@metzdowd.com>,
	Ralf Senderek <crypto@senderek.ie>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com

--===============4569743994999000628==
Content-Type: multipart/alternative; boundary=001a11c3bb34514cbc04ec01d769

--001a11c3bb34514cbc04ec01d769
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Nov 25, 2013 at 1:01 AM, ianG <iang@iang.org> wrote:

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

The problem isn't the certificates, it is leaving the management to end
users.

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.

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.

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.

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.


But that said, the idea of authenticating the sender (i.e. the US military)
is a good one. But the execution is pretty much healthcare.gov. It is a
boondoggle for contractors who are never held accountable for their stuff
not really working right.



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

And the other part of the problem was that PGP does not meet the trust
needs of the enterprises.

There just wasn't the perceived market demand to fix the system.

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

I really think that Snowdonia has opened an opportunity here. I have a
three phase plan

1) Use direct trust exchange (strong email addresses <fingerprint>?
alice@example.com) to allow people to exchange secure mail with people they
know using existing, unmodified mail clients without plug-ins and without
maintenance.

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.

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.


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.


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.





-- 
Website: http://hallambaker.com/

--001a11c3bb34514cbc04ec01d769
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Nov 25, 2013 at 1:01 AM, ianG <span dir=3D"ltr">&l=
t;<a href=3D"mailto:iang@iang.org" target=3D"_blank">iang@iang.org</a>&gt;<=
/span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc 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&#39;t work well enough. =A0It&#39;s a CA&#3=
9;s perfect protocol because it places the cert at the apex of the mission,=
 and a user&#39;s nightmare because certs fail too frequently in the aggreg=
ate to avoid the curse of K6 -- turn it off, dump it. =A0In practical impor=
t (from actual experience), if you had a group of say 12 people with one ye=
ar 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&#39;t the certificates, it=
 is leaving the management to end users.</div><div><br></div><div>S/MIME wa=
s designed for enterprise use based on experience of the military email sys=
tem. 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&#39; =
PR guy, a Col. Boylan lying about having sent Greenwald an email. What happ=
ened 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 point=
ing 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 nu=
mbers in the headers.=A0</div>
<div><br></div><div>The point here being that accountability is also import=
ant. If someone had been impersonating Boylan in that message it should hav=
e been a major concern. There should have been an enquiry because it is rat=
her significant when the enemy might be injecting false communications as B=
oylan 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=3D"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>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
PGP failed because it never succeeded in conquering the GUI clients. That w=
as in part because of what PHB calls the Betamax-VHS war. =A0The providers =
of the major clients were already in the certificate camp, so they locked o=
ut the PGP side. =A0It was beyond the resources of the PGP group to crack t=
hat 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&#39;t the perceived market demand to fix the system.</=
div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">Hence, I&#39;ve concluded tha=
t email is unsecurable. =A0Obviously Jon and PHB and Ladar think differentl=
y. =A0I applaud their efforts and hope they prove me wrong. =A0But the less=
ons of Skype and Facebook and Netscape are writ very large -- great securit=
y achievements come from 3 party networks, not 4 party networks.<br>
</blockquote></div><div><br></div><div>I really think that Snowdonia has op=
ened an opportunity here. I have a three phase plan</div><div><br></div><di=
v>1) Use direct trust exchange (strong email addresses &lt;fingerprint&gt;?=
<a href=3D"mailto:alice@example.com">alice@example.com</a>) to allow people=
 to exchange secure mail with people they know using existing, unmodified m=
ail clients without plug-ins and without maintenance.</div>
<div><br></div><div>2) Build out infrastructure to support other trust mode=
ls including CA trust and peer-endorsements and trust discovery. Can now se=
nd 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 ove=
r TLS.</div>
<div><br></div><div><br></div><div>We won&#39;t get to protect meta data pr=
operly till we get to step 3 but each step is manageable, has significant d=
emand 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 m=
echanism 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=3D"http://hallambaker.com/">http://hallambaker.com/=
</a><br>
</div></div>

--001a11c3bb34514cbc04ec01d769--

--===============4569743994999000628==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============4569743994999000628==--

home help back first fref pref prev next nref lref last post