[146344] in cryptography@c2.net mail archive
Re: [Cryptography] PRISM PROOF Email
daemon@ATHENA.MIT.EDU (Carl Ellison)
Fri Aug 23 19:18:31 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <CAMm+LwisER9-oFW1ExXPnhDfFrw=CCrA3RGLWoV-Xd19Vu0aWw@mail.gmail.com>
From: Carl Ellison <cme@acm.org>
Date: Fri, 23 Aug 2013 09:38:21 -0700
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============4119328306306554051==
Content-Type: multipart/alternative;
boundary=Apple-Mail-4FE8B395-A3F4-4D15-9B35-6A71D559B278
Content-Transfer-Encoding: 7bit
--Apple-Mail-4FE8B395-A3F4-4D15-9B35-6A71D559B278
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Ease of use implies ubiquitous deployment. Seeing how hard it was to get tha=
t in mail clients I'm not sanguine. Then there's the move to web mail. Clien=
ts with keys may be a thing of the past but keys in web servers are subject t=
o national security letters.=20
Meanwhile PRISM was more about metadata than content, right? How are we goin=
g to prevent traffic analysis worldwide?
Carl
Sent from my phone
On Aug 22, 2013, at 2:36 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> Thanks to Snowden we now have a new term of art 'Prism-Proof', i.e. a secu=
rity scheme that is proof against state interception. Having had an attack b=
y the Iranians, I am not just worried about US interception. Chinese and Rus=
sian intercepts should also be a concern.
>=20
> 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 t=
o use. The problem Snowden faced was that even if he could grok PGP, the peo=
ple sending him emails probably couldn't.
>=20
>=20
> So to be properly PRISM-Proof an email security solution must be both proo=
f against state interception and easy enough to use that it can build critic=
al mass.=20
>=20
> By easy enough to use, I mean 'absolutely no additional effort to installa=
tion of an email client'. Everything has to be transparent to the end user w=
ho is not a crypto expert and may well be a bit of a doof.
>=20
>=20
> The traditional approach to making a system intercept proof is to eliminat=
e the intermediaries. PGP attempts to eliminate the CA but it has the unfort=
unate effect on scalability. Due to the Moore bound on a minimum diameter gr=
aph, it is only possible to have large graphs with a small diameter if you h=
ave nodes of high degree. If every PGP key signer signs ten other people the=
n 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.=20
>=20
> End to end has an unfortunate effect on usability as well.=20
>=20
>=20
> My solution is to combine my 'Omnibroker' proposal currently an internet d=
raft and Ben Laurie's Certificate Transparency concept.=20
>=20
> Omnibroker introduces a trust agent for the relying party to match the tru=
st agent for the key holder (the CA). So rather than have the usual problem o=
f the CA being selected by one side but delivering trust to the other, each s=
ide in the transaction has 'representation'.=20
>=20
> http://datatracker.ietf.org/doc/draft-hallambaker-omnibroker/
>=20
>=20
> Since email is an asynchronous protocol there is no reason not to check fo=
r CT proofs everywhere we can. But the omnibroker selected by a user has the=
primary responsibility for keeping them safe. This means finding an encrypt=
ion key for the intended recipient of an email and verifying it, if this is p=
ossible. If not, the broker returns evidence to the contrary (if this is pos=
sible).
>=20
>=20
> So the way this would work is that to use the system you would either inst=
all a PPE aware email client or a pair of SMTP/IMAP proxies that are PPE awa=
re.
>=20
> Whenever an email is sent the PPE client queries its local cache and the o=
mnibroker to determine if there is an encryption key on file for it. If so, t=
he email will be sent encrypted. The PPE client could in theory access any k=
ey store including existing PGP key stores. It can also implement rules like=
'email sent to x.com must be encrypted'.
>=20
> I believe that the user interface can be made essentially zero effort. If t=
he installer for a proxy set knows how the email app stores the configuratio=
n data for mail servers, it can even rewrite these automatically.
>=20
>=20
> Preventing key substitution will require a combination of the CT ideas pro=
posed by Ben Laurie (so catenate proof notaries etc) and some form of 'no ke=
y exists' demonstration.
>=20
> For spam control reasons, every email sent has to be authenticated which m=
eans using digital signatures on the message (and likely DKIM + SSL client a=
uth).
>=20
>=20
> --=20
> Website: http://hallambaker.com/
> _______________________________________________
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
--Apple-Mail-4FE8B395-A3F4-4D15-9B35-6A71D559B278
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div>Ease of use implies ubiquitous deploym=
ent. Seeing how hard it was to get that in mail clients I'm not sanguine. Th=
en there's the move to web mail. Clients with keys may be a thing of the pas=
t but keys in web servers are subject to national security letters. </d=
iv><div><br></div><div>Meanwhile PRISM was more about metadata than content,=
right? How are we going to prevent traffic analysis worldwide?</div><div><b=
r></div><div>Carl<br><br><div><br></div>Sent from my phone<div><br></div></d=
iv><div><br>On Aug 22, 2013, at 2:36 AM, Phillip Hallam-Baker <<a href=3D=
"mailto:hallam@gmail.com">hallam@gmail.com</a>> wrote:<br><br></div><bloc=
kquote type=3D"cite"><div><div dir=3D"ltr">Thanks to Snowden we now have a n=
ew term of art 'Prism-Proof', i.e. a security scheme that is proof against s=
tate interception. Having had an attack by the Iranians, I am not just worri=
ed about US interception. Chinese and Russian intercepts should also be a co=
ncern.<div>
<br></div><div>We have two end to end security solutions yet Snowden used ne=
ither. If PGP and S/MIME are too hard to use for the likes of Snowden, they a=
re 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 se=
curity solution must be both proof against state interception and easy enoug=
h to use that it can build critical mass. </div><div><br></div><div>By e=
asy enough to use, I mean 'absolutely no additional effort to installation o=
f an email client'. Everything has to be transparent to the end user who is n=
ot 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 syst=
em intercept proof is to eliminate the intermediaries. PGP attempts to elimi=
nate the CA but it has the unfortunate effect on scalability. Due to the Moo=
re bound on a minimum diameter graph, it is only possible to have large grap=
hs with a small diameter if you have nodes of high degree. If every PGP key s=
igner signs ten other people then we have to trust key chains of 6 steps to s=
upport even a million users and nine to support a global solution of a billi=
on users. </div>
<div><br></div><div>End to end has an unfortunate effect on usability as wel=
l. </div><div><br></div><div><br></div><div>My solution is to combine m=
y 'Omnibroker' proposal currently an internet draft and Ben Laurie's Certifi=
cate Transparency concept. </div>
<div><br></div><div>Omnibroker introduces a trust agent for the relying part=
y to match the trust agent for the key holder (the CA). So rather than have t=
he usual problem of the CA being selected by one side but delivering trust t=
o the other, each side in the transaction has 'representation'. </div>
<div><br></div><div><a href=3D"http://datatracker.ietf.org/doc/draft-hallamb=
aker-omnibroker/">http://datatracker.ietf.org/doc/draft-hallambaker-omnibrok=
er/</a><br></div><div><br></div><div><br></div><div>Since email is an asynch=
ronous protocol there is no reason not to check for CT proofs everywhere we c=
an. But the omnibroker selected by a user has the primary responsibility for=
keeping them safe. This means finding an encryption key for the intended re=
cipient of an email and verifying it, if this is possible. If not, the broke=
r 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 S=
MTP/IMAP proxies that are PPE aware.</div><div><br></div><div>Whenever an em=
ail is sent the PPE client queries its local cache and the omnibroker to det=
ermine if there is an encryption key on file for it. If so, the email will b=
e sent encrypted. The PPE client could in theory access any key store includ=
ing existing PGP key stores. It can also implement rules like 'email sent to=
<a href=3D"http://x.com">x.com</a> must be encrypted'.</div>
<div><br></div><div>I believe that the user interface can be made essentiall=
y zero effort. If the installer for a proxy set knows how the email app stor=
es the configuration data for mail servers, it can even rewrite these automa=
tically.</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 notar=
ies etc) and some form of 'no key exists' demonstration.</div>
<div><br></div><div>For spam control reasons, every email sent has to be aut=
henticated which means using digital signatures on the message (and likely D=
KIM + SSL client auth).</div><div><div><br clear=3D"all"><div><br></div>
-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallambaker.com/<=
/a><br>
</div></div></div>
</div></blockquote><blockquote type=3D"cite"><div><span>____________________=
___________________________</span><br><span>The cryptography mailing list</s=
pan><br><span><a href=3D"mailto:cryptography@metzdowd.com">cryptography@metz=
dowd.com</a></span><br><span><a href=3D"http://www.metzdowd.com/mailman/list=
info/cryptography">http://www.metzdowd.com/mailman/listinfo/cryptography</a>=
</span></div></blockquote></body></html>=
--Apple-Mail-4FE8B395-A3F4-4D15-9B35-6A71D559B278--
--===============4119328306306554051==
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
--===============4119328306306554051==--
