[146346] in cryptography@c2.net mail archive
Re: [Cryptography] PRISM PROOF Email
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Fri Aug 23 19:19:51 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <13082310421905_1F34E@oregon.uoregon.edu>
Date: Fri, 23 Aug 2013 19:05:29 +0100
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Joe St Sauver <joe@oregon.uoregon.edu>
Cc: cryptography@metzdowd.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============8938116240697690143==
Content-Type: multipart/alternative; boundary=047d7b5dbcda818ed004e4a14072
--047d7b5dbcda818ed004e4a14072
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Aug 23, 2013 at 6:42 PM, Joe St Sauver <joe@oregon.uoregon.edu>wrote:
>
> I wouldn't take Snowden's alleged opsec practice, or lack thereof, as
> a demonstration proof that PGP and/or S/MIME are impossibly difficult for
> technical people (or even motivated NON-technical people) to use when
> necessary or appropriate.
>
Thats what the IETF folk told us when I worked on HTTP 0.9 against Gopher
and FTP.
Usability matters. In fact it is all that matters for adoption. Angry Birds
has made a billion dollars because it is so nice to use that people will
pay to use it.
-- most email clients only integrate support for S/MIME; if you want
> to try to push anything else, your mission effectively devolves to
> advocating for native support for PGP in popular email clients (such
> as Thunderbird and Outlook), but when you do so, be prepared for
> pushback.
>
Yep, I see no particular value in pushing PGP over S/MIME. Other than the
fact that it has mind share.
-- "PRISM-proofing" isn't just about encryption, since traffic analysis
> doesn't require full contents (and in fact, arguably, encryption ENHANCES
> traffic analysis in some ways, depending on how it ends up being used).
>
Thats why message layer security is not a substitute for TLS. And the TLS
should be locked to the email service via a policy statement such as DANE.
> #Everything has to be transparent to the
> #end user who is not a crypto expert and may well be a bit of a doof.
>
> You simply cannot produce doof-proof message-level crypto (I'd be
> surprised if there isn't already a CafePress tee shirt with this meme,
> in fact), any more than you can keep doofs from driving their cars
> into other vehicles, etc.
>
I disagree. I think it is entirely tractable.
If I understand your architecture correctly, it isn't end-to-end, is it?
> If it isn't end-to-end, that just means that the attack point shifts,
> it doesn't get eliminated.
>
Depends on what you call the ends.
The messages are encrypted email client to email client. But the trust
relationships run from the CA to the Omnibroker. If you want to have full
control then you would run your own omnibroker and configure it with the
appropriate policy. If you are worried about foreign governments
intercepting your email but not your own then a Symantec or Comodo provided
Omnibroker service would be acceptable.
People who trust us sufficiently to run our anti-virus are already trusting
us to a far greater degree.
> And remember, end-to-end encryption isn't free. You may be reducing the
> risk of message eavesdropping, but the tradeoff may be that malicious
> content doesn't get scanned and blocked prior to delivery, just to
> mention one potential concern. (And of course, if your endpoint gets
> 0wn3d, your privacy expectations shouldn't be very high, right?)
>
Which is one reason people would run their own omnibroker in certain
situations (like enterprise) and encrypted mail is likely to be subject to
policy controls (no executables) and only accepted from known parties with
established reputations.
> #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).
>
> Auth doesn't prevent spam. Auth just enables the accumulation of
> reputation,
> which can then drive filtering decisions.
>
Which is what most spam filtering works of these days, content filtering is
not a very successful anti-spam strategy.
--
Website: http://hallambaker.com/
--047d7b5dbcda818ed004e4a14072
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, Aug 23, 2013 at 6:42 PM, Joe St Sauver <span dir=3D"ltr">&l=
t;<a href=3D"mailto:joe@oregon.uoregon.edu" target=3D"_blank">joe@oregon.uo=
regon.edu</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I wouldn't take Snowden's alleged opsec practice, or lack thereof, =
as<br>
a demonstration proof that PGP and/or S/MIME are impossibly difficult for<b=
r>
technical people (or even motivated NON-technical people) to use when<br>
necessary or appropriate.<br></blockquote><div><br></div><div>Thats what th=
e IETF folk told us when I worked on HTTP 0.9 against Gopher and FTP.=A0</d=
iv><div><br></div><div>Usability matters. In fact it is all that matters fo=
r adoption. Angry Birds has made a billion dollars because it is so nice to=
use that people will pay to use it.=A0</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">-- most email clients only in=
tegrate support for S/MIME; if you want<br>
to try to push anything else, your mission effectively devolves to<br>
advocating for native support for PGP in popular email clients (such<br>
as Thunderbird and Outlook), but when you do so, be prepared for<br>
pushback.<br></blockquote><div><br></div><div>Yep, I see no particular valu=
e in pushing PGP over S/MIME. Other than the fact that it has mind share.</=
div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">
-- "PRISM-proofing" isn't just about encryption, since traffi=
c analysis<br>
doesn't require full contents (and in fact, arguably, encryption ENHANC=
ES<br>
traffic analysis in some ways, depending on how it ends up being used).<br>=
</blockquote><div><br></div><div>Thats why message layer security is not a =
substitute for TLS. And the TLS should be locked to the email service via a=
policy statement such as DANE.</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">
#Everything has to be transparent to the<br>
#end user who is not a crypto expert and may well be a bit of a doof.<br>
<br>
You simply cannot produce doof-proof message-level crypto (I'd be<br>
surprised if there isn't already a CafePress tee shirt with this meme,<=
br>
in fact), any more than you can keep doofs from driving their cars<br>
into other vehicles, etc.<br></blockquote><div><br></div><div>I disagree. I=
think it is entirely tractable.=A0</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
If I understand your architecture correctly, it isn't end-to-end, is it=
?<br>
If it isn't end-to-end, that just means that the attack point shifts,<b=
r>
it doesn't get eliminated.<br></blockquote><div><br></div><div>Depends =
on what you call the ends.</div><div><br></div><div>The messages are encryp=
ted email client to email client. But the trust relationships run from the =
CA to the Omnibroker. If you want to have full control then you would run y=
our own omnibroker and configure it with the appropriate policy. If you are=
worried about foreign governments intercepting your email but not your own=
then a Symantec or Comodo provided Omnibroker service would be acceptable.=
</div>
<div><br></div><div>People who trust us sufficiently to run our anti-virus =
are already trusting us to a far greater degree.</div><div>=A0<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
And remember, end-to-end encryption isn't free. You may be reducing the=
<br>
risk of message eavesdropping, but the tradeoff may be that malicious<br>
content doesn't get scanned and blocked prior to delivery, just to<br>
mention one potential concern. (And of course, if your endpoint gets<br>
0wn3d, your privacy expectations shouldn't be very high, right?)<br></b=
lockquote><div><br></div><div>Which is one reason people would run their ow=
n omnibroker in certain situations (like enterprise) and encrypted mail is =
likely to be subject to policy controls (no executables) and only accepted =
from known parties with established reputations.</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">
#For spam control reasons, every email sent has to be authenticated which<b=
r>
#means using digital signatures on the message (and likely DKIM + SSL clien=
t<br>
#auth).<br>
<br>
Auth doesn't prevent spam. Auth just enables the accumulation of reputa=
tion,<br>
which can then drive filtering decisions.<br></blockquote><div><br></div><d=
iv>Which is what most spam filtering works of these days, content filtering=
is not a very successful anti-spam strategy.=A0</div></div><br clear=3D"al=
l">
<div><br></div>-- <br>Website: <a href=3D"http://hallambaker.com/">http://h=
allambaker.com/</a><br>
</div></div>
--047d7b5dbcda818ed004e4a14072--
--===============8938116240697690143==
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
--===============8938116240697690143==--
