Re: [perpass] A proposal for developing PRISM-Proof email

[[e-mail]]

> * SM wrote:
> >At 05:46 22-09-2013, Bjoern Hoehrmann wrote:
> >>Another scenario is that the supposedly secure email system relies on
> >>personal private long-term cryptographic secrets, and then the system
> >>becomes popular. How long before helpful cloud backup and cross device
> >>synchronisation systems compromise the keys? For that matter, how many
> >>will surrender the keys freely to their web mail system, for spam and
> >>virus checks, or a coupon? On Google's Android system you can get some
> >>cloud backup service, but only if you let Google have all "your" Wi-Fi
> >>passwords (which often aren't yours to share with Google).
> >
> >I'll comment on a part of the above only.  The receiver no longer has
> >the ability to perform spam and virus verifications when the message
> >(body) is encrypted.  The receiver can ask the users for their keys
> >to perform those verifications.  That is already done in unrelated
> >scenarios and some of the users hand over their passwords [1].

> Whoever is meant to read the message can perform, and ask others to
> perform, spam and virus checks as they see fit, with little need to
> reveal much about the message to third parties (by employing fully
> homomorphic encryption, generating noise, pulling blacklists in full
> instead of pushing specific items to a third party to check whether
> they are on the blacklist, for instance) and the ability to do so
> selectively (mails from people I have had a lot of contact with in
> the past do not need to be checked for spam, while I might not mind
> if strangers have to jump through extra hoops to send confidential
> mails to me). That's not on the path of least resistance, of course.

OK... So I believe the goal here to make it harder if not impossible to perform
widespread surveilance on and interception of Internet traffic.

In the case of email, meeting that goal with end-to-end encryption mechanisms
like S/MIME or PGP is necessarily going to mean having a nonnegligable amount
of email traffic encrypted. The minute that happens spammers are going to join
the party in a big way precisely because of the ability this confers to get
past transport-side content inspection and filtering.

State of the art AS/AV vendors employ honeypots and other forms of feedback to
rapidly generate rules, patterns, hashes, and other information, which is then
rapidly distributed to filtering systems attached to vast numbers of ingress
MTAs operated by their customers. Some of this filtering is done on the basis
of IP addresses, envelope, or outer header information, but a lot of it depends
on content analysis - analysis that will be blocked by encryption.

Even so, nasty stuff still makes it through, so vendors also implement various
schemes to "undeliver" mail containing malware that was only detected after
the fact. These mechanisms are if anything even more dependent on content
analysis than ingress filtering is.

It follows that one effect of the widespread use of end-to-end encryption will
be an *enormous* increase in the amount of spam and malware that can't be
blocked at the transport layer and will end up getting delivered to user
mailboxes. Irrespective of what happens to this email after delivery, it's
going to represent a significant cost increase to ISPs and MSPs. Any plan to
significantly increase the use of end-to-end encryption is going to have to
address this issue.

And as for what happens to spam and malware-laden email after delivery, one
reason that things have shifted to a centralized scanning approach is it's been
shown over and over and over again that end users cannot be relied upon to
perform this sort of filtering themselves. So this is another issue that is
going to have to be addressed - how filtering can done reliably at this stage.

For better or worse, while the IETF has been spending time holding PGP key
signing parties and designers the S/MIME extension du jour, the ISPs and MSPs
have been busy building a vast infrastructure used by hundreds of millions if
not billions of people that is heavily dependent on the *lack* of widespread
use of end-to-end encryption. (The need for content analysis by AS/AV
mechanisms is only one example of this; there are many others.)

Any halfway realistic plan to deploy end-to-end encryption at Internet scale is
going to have deal with the totality of contemporary email services and usage
in addition to solving the myriad problems surrounding key/certificate
distribution and management as well as UI issues. (As if the latter weren't
difficult enough.)

Finally, the desire to address the surveilance/intercept problem may be so
strong that people may be tempted to dismiss these sorts of issues as "someone
else's problem". So let me close by noting that quite a lot of spam originates
from infected PCs, and is done by sending those messages using whatever
submission mechanism that user uses, borrowing their credentials in the
process. And if those credentials include a private key, that's going to be
borrowed as well. Anything that increases the rate at which malware makes it to
end user mail accounts is going to increase the rate of infection, and that in
turn is going to compromise the integrity of the end-to-end security system
you're trying to deploy.

				Ned