<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 23, 2013 at 6:42 PM, Joe St Sauver <span dir="ltr"><<a href="mailto:joe@oregon.uoregon.edu" target="_blank">joe@oregon.uoregon.edu</a>></span> wrote:<blockquote class="gmail_quote" style="margin: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<br>
technical people (or even motivated NON-technical people) to use when<br>
necessary or appropriate.<br></blockquote><div><br></div><div>Thats what the IETF folk told us when I worked on HTTP 0.9 against Gopher and FTP. </div><div><br></div><div>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. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-- most email clients only integrate 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 value in pushing PGP over S/MIME. Other than the fact that it has mind share.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-- "PRISM-proofing" isn't just about encryption, since traffic analysis<br>
doesn't require full contents (and in fact, arguably, encryption ENHANCES<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> </div><blockquote class="gmail_quote" style="margin: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. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-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,<br>
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 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.</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> <br></div><blockquote class="gmail_quote" style="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></blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
#For spam control reasons, every email sent has to be authenticated which<br>
#means using digital signatures on the message (and likely DKIM + SSL client<br>
#auth).<br>
<br>
Auth doesn't prevent spam. Auth just enables the accumulation of reputation,<br>
which can then drive filtering decisions.<br></blockquote><div><br></div><div>Which is what most spam filtering works of these days, content filtering is not a very successful anti-spam strategy. </div></div><br clear="all">
<div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>