[Cryptography] PRISM PROOF Email

[Phillip Hallam-Baker]

On Fri, Aug 23, 2013 at 6:42 PM, Joe St Sauver <joe at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20130823/7aca87bd/attachment.html>