[147219] in cryptography@c2.net mail archive
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Wed Sep 18 13:26:16 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <20130918080532.39aba2d8@jabberwock.cb.piermont.com>
Date: Wed, 18 Sep 2013 09:08:04 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>,
Christian Huitema <huitema@huitema.net>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============6086539233336103076==
Content-Type: multipart/alternative; boundary=001a1132f26ab0731304e6a8204a
--001a1132f26ab0731304e6a8204a
Content-Type: text/plain; charset=ISO-8859-1
A few clarifications
1) PRISM-Proof is a marketing term
I have not spent a great deal of time looking at the exact capabilities of
PRISM vs the other programs involved because from a design point they are
irrelevant. The objective is to harden/protect the infrastructure from any
ubiquitous, indiscriminate intercept capability like the one Gen Alexander
appears to have constructed.
PRISM-class here is merely a handy label for a class of attack where the
attacker can spend upwards of $100 million to perform an attack which
potentially affects every Internet user. PRISM-class is a superset of
PRISM, BULLRUN, MANASAS, etc. etc.
2) SSL is not designed to resist government intercept
Back in 1993-6 when I was working on Internet security and payments at CERN
and the Web Consortium the priority was to make payments on the Web, not
make it resistant to government intercept. The next priority was to
establish the authenticity of news Web sites. There were several reasons
for that set of priorities, one of which was that the technology we had
available was limited and it was impractical to do more than one public key
operation per session and it was only practical to use public key some of
the time. Severs of the day simply could not handle the load otherwise.
Twenty years later, much has changed and we can do much more. The designs
do not need to be constrained in the way they were then.
It is not a question of whether email is encrypted in transport OR at rest,
we need both. There are different security concerns at each layer.
3) We need more than one PKI for Web and email security.
PGP and S/MIME have different key distribution models. Rather than decide
which is 'better' we need to accept that we need both approaches and in
fact need more.
If I am trying to work out if an email was really sent by my bank then I
want a CA type security model because less than 0.1% of customers are ever
going to understand a PGP type web of trust for that particular purpose.
But its the bank sending the mail, not an individual at the bank.
--001a1132f26ab0731304e6a8204a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">A few clarifications<div><br></div><div>1) PRISM-Proof is =
a marketing term</div><div><br></div><div>I have not spent a great deal of =
time looking at the exact capabilities of PRISM vs the other programs invol=
ved because from a design point they are irrelevant. The objective is to ha=
rden/protect the infrastructure from any ubiquitous, indiscriminate interce=
pt capability like the one Gen Alexander appears to have constructed.=A0</d=
iv>
<div><br></div><div>PRISM-class here is merely a handy label for a class of=
attack where the attacker can spend upwards of $100 million to perform an =
attack which potentially affects every Internet user. PRISM-class is a supe=
rset of PRISM, BULLRUN, MANASAS, etc. etc.=A0</div>
<div><br></div><div><br></div><div>2) SSL is not designed to resist governm=
ent intercept</div><div><br></div><div>Back in 1993-6 when I was working on=
Internet security and payments at CERN and the Web Consortium the priority=
was to make payments on the Web, not make it resistant to government inter=
cept. The next priority was to establish the authenticity of news Web sites=
. There were several reasons for that set of priorities, one of which was t=
hat the technology we had available was limited and it was impractical to d=
o more than one public key operation per session and it was only practical =
to use public key some of the time. Severs of the day simply could not hand=
le the load otherwise.</div>
<div><br></div><div>Twenty years later, much has changed and we can do much=
more. The designs do not need to be constrained in the way they were then.=
</div><div><br></div><div>It is not a question of whether email is encrypte=
d in transport OR at rest, we need both. There are different security conce=
rns at each layer.</div>
<div><br></div><div><br></div><div>3) We need more than one PKI for Web and=
email security.</div><div><br></div><div>PGP and S/MIME have different key=
distribution models. Rather than decide which is 'better' we need =
to accept that we need both approaches and in fact need more.</div>
<div><br></div><div>If I am trying to work out if an email was really sent =
by my bank then I want a CA type security model because less than 0.1% of c=
ustomers are ever going to understand a PGP type web of trust for that part=
icular purpose. But its the bank sending the mail, not an individual at the=
bank.</div>
<div><br></div><div><br></div></div>
--001a1132f26ab0731304e6a8204a--
--===============6086539233336103076==
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
--===============6086539233336103076==--
