[146341] in cryptography@c2.net mail archive
[Cryptography] PRISM PROOF Email
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Fri Aug 23 12:26:33 2013
X-Original-To: cryptography@metzdowd.com
Date: Thu, 22 Aug 2013 10:36:48 +0100
From: Phillip Hallam-Baker <hallam@gmail.com>
To: cryptography@metzdowd.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============3497973758273382719==
Content-Type: multipart/alternative; boundary=089e0103eea26f07ed04e486071f
--089e0103eea26f07ed04e486071f
Content-Type: text/plain; charset=ISO-8859-1
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/
--089e0103eea26f07ed04e486071f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks to Snowden we now have a new term of art 'Prism=
-Proof', i.e. a security scheme that is proof against state interceptio=
n. Having had an attack by the Iranians, I am not just worried about US int=
erception. Chinese and Russian intercepts should also be a concern.<div>
<br></div><div>We have two end to end security solutions yet Snowden used n=
either. If PGP and S/MIME are too hard to use for the likes of Snowden, the=
y 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 s=
ecurity solution must be both proof against state interception and easy eno=
ugh to use that it can build critical mass.=A0</div><div><br></div><div>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 u=
ser 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 sys=
tem intercept proof is to eliminate the intermediaries. PGP attempts to eli=
minate 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 st=
eps to support even a million users and nine to support a global solution o=
f a billion users.=A0</div>
<div><br></div><div>End to end has an unfortunate effect on usability as we=
ll.=A0</div><div><br></div><div><br></div><div>My solution is to combine my=
'Omnibroker' proposal currently an internet draft and Ben Laurie&#=
39;s Certificate Transparency concept.=A0</div>
<div><br></div><div>Omnibroker introduces a trust agent for the relying par=
ty to match the trust agent for the key holder (the CA). So rather than hav=
e the usual problem of the CA being selected by one side but delivering tru=
st to the other, each side in the transaction has 'representation'.=
=A0</div>
<div><br></div><div><a href=3D"http://datatracker.ietf.org/doc/draft-hallam=
baker-omnibroker/">http://datatracker.ietf.org/doc/draft-hallambaker-omnibr=
oker/</a><br></div><div><br></div><div><br></div><div>Since email is an asy=
nchronous protocol there is no reason not to check for CT proofs everywhere=
we can. But the omnibroker selected by a user has the primary responsibili=
ty for keeping them safe. This means finding an encryption key for the inte=
nded recipient of an email and verifying it, if this is possible. If not, t=
he 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 us=
e 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 w=
ill be sent encrypted. The PPE client could in theory access any key store =
including existing PGP key stores. It can also implement rules like 'em=
ail 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 essential=
ly zero effort. If the installer for a proxy set knows how the email app st=
ores the configuration data for mail servers, it can even rewrite these aut=
omatically.</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 no=
taries etc) and some form of 'no key exists' demonstration.</div>
<div><br></div><div>For spam control reasons, every email sent has to be au=
thenticated which means using digital signatures on the message (and likely=
DKIM + 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>
--089e0103eea26f07ed04e486071f--
--===============3497973758273382719==
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
--===============3497973758273382719==--
