[messaging] Modern anti-spam and E2E crypto

carlo walentiny cajw1 at web.de
Mon Sep 8 14:38:21 PDT 2014

 >I'd be more worried about usability and what problem it's actually

Forget about encryption and think people.

Magic, wondrous email enables
anybody - worldwide - to email you!

Let's divide all the people on planet
earth into three sets:

{1} people you know;

{2} people you don't know but who know [something about] you
which makes them think that you would be interested in getting
to know them/talk to them about something of mutual interest;

{3} people who don't know you -> some of these write botnets
that spam you because of an x% chance to make some money.

For most of us, the cardinality of sets {1} and {2}
is small enough that we _want_ to _see_ all email messages
sent by people in {1} and {2}. We might not want to _reply_
to messages in {2}, but we want to read them to decide.

(For the Paul Grahams of this world where this is not true,
there is no solution but to pay for extra eyeballs to help
process their email stream.)

Unfortunately, for all of us, most emails received are from {3}.
This is the least important stuff (or if it is a notification
from a shop you just bought from the first time, you will know
to go and look for it the minute after you purchased or when
you need it).

A good email client must be able to divide received
emails into {1}, {2} and {3} because emails from {3}
dominate and would otherwise visually obscure the
good stuff. Also note that anything in {2} cannot be
auto-replied-to by the email client, you have to read
and evaluate the pitch yourself.

I don't think this is easy to do:

{1} is nearly trivial,
but distinguishing between {2} and {3} is very hard
(if you think that is what current ESP spam filters do,
simply pretend you are solving for the "first email contact
with new email address should already be e2e encrypted" case
where you cannot rely on ESP help).

Unfortunately is is essential from a "delight the user"
point of view to distinguish between {2} and {3} because
emails from {3} fully dominate emails from {2}, and it
is very undelightful to have to filter them out oneself.

==> Usecase (the problem it is trying to solve):

1. The [politely] protocol is meant to trivially help your email
client distinguish between {2} and {3} (ideally even without
the help of your ESP's spam filter if for example you run
it over an encrypted channel).

2. Since only you can be the final judge of whether a
"pitch for attention" is valid or not, the protocol is
further designed (text-only one-paragraph) to help you
process these pitches as quickly as possible (in case
you are a half-graham and get loads of them, or in case
some people in {3} abuse it):

-> a twitter-like stream of short one-paragraph pitches does
not take long to skimread/scroll through (and it is ok
to not reply, people in {2} know they might have to and
are allowed to retry again later).

3. The protocol must successfully discourage abuse by
99.999007% of people in {3} or we are back to commingled
{2} and {3}. (Getting there without ESP help might be tricky.)

So the protocol is orthogonal to encryption.
It's just that
if you only want to accept encrypted email from {1}
then you need a "safe and delightful enough" way to process
emails from {2} and decide which ones are allowed into {1}


For now just two observations:

1. Usefulness/Sacrifice of a cleartext opening message:

a. If it is a politely handshake ({2}),
it is only a pitch for attention written to convince you
that the person is indeed in {2}, ie mainly that he knows
(sth about) you. The real-life equivalent: at a conference,
with lots of people around overhearing you, you approach the
speaker and ask him if you could talk about your secret
idea  directly relevant to his field of expertise somewhere

b. If it is another email in {3} which you choose to reply
to (and for some reason the sender is e2e enabled but did
not use the politely protocol): better now than never.

c. All your current conversations with your friends {1} are
probably in the clear at your ESP. This is worse than just a
first message, yet I guess you would still switch to e2e encrypted
with them asap?

2. Metadata in the clear:

Here's my pessimistic threat model:

- a big brother active(*) global adversary,
- interested in eavesdropping and metadata (who with whom when),
- everything that goes over the wire is monitored in realtime,
- and persisted somewhere (for eventual later use).

(*) "active" only as needed to hide MITM attacks, not
to impersonate or semantically modify content, the
aim is "undetected passive listening in" and
"network analysis".

In this model I just assume the adversary knows/can infer
the metadata, whether I encrypt it or not (TOR is assumed
crackable in my model). In case it isn't obvious,
IANAC (I am not a cryptographer), so simplifying
to pessimist.

I also assume that a real solution which enables secure
_anonymous_ communication [over email] with this kind of adversary
is not going to be deployed (to millions of users) anytime soon.

So for now: big brother does have the metadata (who with whom when).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140908/fd16ec4a/attachment.html>

More information about the Messaging mailing list