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

From: Mike Demmers <[email-masked]>
Date: Wed, 25 Sep 2013 11:09:34 -0700

> 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.

This is a real serious problem.

But it may also be an unprecedented golden opportunity.

The reason we have spam is that email is default 'permit'. 

What if encrypted email were default 'deny'?

This would require the user whitelist anyone that was to be communicated with in encrypted email.

The normal unencrypted systems would still be in place, default 'permit', and all the filtering would still work just as before. 

So, the very first time I email someone, it MUST be in plain text. They then whitelist me (if they wish), and henceforth our mail is encrypted. 

If you labeled the whitelist or blacklist buttons 'Friend' and 'Unfriend' probably millions of people would use such a system reflexively.

This would require some technical changes - the email server would need to have a list of whitelisted people for each user. I think most large systems probably already have a way for individual users to whitelist or blacklist addresses or envelope senders, so that shoud not be too difficult. And these lists would be small, most people only communicate with a few others - family, friends, work.

There would need to be some way for mail server to mail server connections to indicate a message is encrypted, since at that point the server sees only the connecting ip and envelope sender. Perhaps that could be done by another hack on 'HELO' in the connection dialog (as is done now to indicate extended commands with 'EHLO'), perhaps something like changing the last letter to E, 'EHLE'. (E for encrypted ;-) )

From the user agent point of view, if you want 'default to encrypted', the user agent could try to send encrypted, if that fails, let the user know immediately and ask them if they wish to send unencrypted.

I think the changes needed to do this might be pretty easy to make; in Sendmail, at least, they could probably be done just though the normal sendmail.cf and some scripts.

> 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.

Consider the result under a default deny system. If a spammer has hacked a machine, they may be able to use the users credentials, but they can ONLY send encrypted emails to someone who has whitelisted them. So they can't hack a machine and send out 10,000 emails - only ONE would actually be accepted. Their remaining choice would be to send unencrypted, in which case the usual filtering would be applied.

Over time, as more and more people used encrypted email, spammers would have a harder time of it.

-Mike

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Sep 2013 21:12:37 +0100

I think that's kinda inventive. A good try at least. I've no
idea if it could fly, but it is a possible answer to the good
point Ned makes.... maybe. (Apologies to whoever suggested it
before, if someone did.)

S.

On 09/25/2013 07:09 PM, Mike Demmers wrote:
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

---

From: Mike Demmers <[email-masked]>
Date: Mon, 30 Sep 2013 13:51:50 -0700

Some more thoughts on default deny for encrypted email. 
(Sorry about the length, I am known for that).

I am interested in this because I think Ned has it exactly right: 

Users are simply not going to put up with encryption that results in (from what
I see on my servers) 100 times or more the amount of spam.

And if ALL email is encrypted, we will be directly attacking the large services
business models: they will fight this tooth and nail and that is a fight I
doubt we can win.

Email is one of the most used services, along with the web and dns. It is also
the closest to someones 'letters and papers', the stuff we would like to be
private.  Transport level encryption only is not going to solve this as there
are too many bad actors in between. We cannot just let this go.

So some sort of compromise is needed. I don't know if this is the -best- idea, but
if not this, what? The likely result of this would be that people encrypt mail
to their friends, family, and maybe work, but not for things like Amazon orders.
Since the large services are really more interested in what I want to buy
than my notes to my children, this should accommodate their needs to
show me better ads, etc. And they would be wise to support something like this,
since the alternative may be, increasingly, 'all email encrypted by default'.

The best way to see the flaws in an idea is to actually try to implement it. So
I have been going through the steps (mentally only, so far) to do this.

I had a look at RFC-5321 (apparently 821 is out of date ;-) ). There is no need
to mess with 'HELO' 'EHLO'. There is already a mechanism for adding extended
commands, that is what EHLO is all about [insert sound of palm slapping head
here]. IANA maintains the list at 

http://www.iana.org/assignments/mail-parameters 

and there is a clear process to add new commands.

I realized there is another clear use case than default rejection of encrypted,
mail - it is the exact opposite of this. If you are in an environment that must
be REALLY secure, say, a defense contractor, etc., you might want to force ALL
email to be encrypted, and reject all others. But humans make errors, so it
might be useful to have a situation where all unencrypted email is rejected,
and only encrypted email would be allowed to be sent. If done by the server (in
this case the server acting as the submission server), a user who accidentally 
had encryption turned off would get an immediate rejection and be unable to
send the email at all - this is much better than say, filtering, where the
email (between offices, say) would have gone out in the clear before being
rejected. 

Another realization I had was that if used as described below, this actually
creates a user controllable mechanism for default deny even on unencrypted
emails, since the MTA just believes what the MUA tells it about the status of the
email. The user just needs to lie about whether the email is encrypted. While
seemimgly useless, this could actually have some use in filtering.

TThe basic concept of default deny for encrypted emails only seems very 'right' to
me, because if you are going to the trouble to do this, and handle things like
key exchanges, that communication must be pretty special to begin with. Why would
you want 'just anyone' to be able to send you encrypted emails?

So the problem boils down to this: 

1. To create a way for the information that an email is encrypted by the MUA
(Mail User Agent or other source) to be passed to the MTA, and all succeeding
MTAs, and for the MTA (relay, submission agent, etc.) to be able to make
delivery or other decisions on the basis of that status.

2. Additionally, there must be a way for users to whitelist or blacklist email,
on a per user basis, and have the MTA be able to make use of those lists.

Ideally we could make some new commands and all the MTAs and MUAs would ugrade
and everything would be wonderful. Of course that is not how the real world (or
the internet) actually works, so we must deal with that reality. There will
always be a mix of upgraded and not upgraded systems.

There are many different MUAs (hundreds ?), but really just a FEW (maybe 6 or
so?) MTAs in common use. The MTAs also tend to be run by businesses, with
system administrators, and be upgraded relatively frequently, especially
compared to the users mail programs. So it would make sense to put as much of
the functionality and changes needed into the MTAs, and even better have a way
to use this system even if the users MUA does not support it yet.

There should also be a way to handle the situation where an MTA in between two
other MTAs that are updated is not, so the information would be lost.

So, walking through this step by step:

The first problem is how the information that an email is encrypted get passed
to the MTA?

We would have a new extended mail command registered, perhaps 'PRECRYPTED'.
The user agent engages in the submission dialog, with EHLO, if that is ok
(meaning the MTA understands extended mail commands), it issues PRECRYPTED
(meaning the next message is encrypted by the MUA). If the MTA gives an error at
that point, the MUA knows it does not understand this command and proceeds
accordingly.

Now, what if the NUA does not yet understand this setup, a likely scenario at
first? How can the user tell the MTA that an email is encrypted? I suggest two
ways.

Many MUAs allow the user to set headers. So we have some standard headers that
indicate this. Something like:

ENCRYPTION: MUA

which indicates 'the message has been previously encrypted by the user'. Other
things might be on the right side, such as 'TRANSPORT' meaning use transport
level encryption for this message if available, or -require- transport level
encryption. Or perhap some other use.

That would be a required header.

Another, optional header might be something like:

ENCRYPTION-TYPE: PGP

Optional, because the user may not want to make that information available.

Now we need one rule for the updated, aware MUA: If it is going to indicate an
email is previously encrypted, it MUST also add an ENCRYPTION:MUA header. (This
covers the case where only the originating MUA and the last MTA are updated,
see below.)

Ok, so what if the users MUA doesn't even allow for adding headers? Thanks again
to Ned for reminding me of this by his use of a plussed address (ned+perpass). We
have a standard 'plussed' address of '+precrypted' which means the email is
encrypted. So our user with a really dumb email program may simply adds this to
his email that is encrypted to insure it will get through.

Now let's add some rules for the MTA:

If an MTA is informed by any means that an email is previously encrypted, it
MUST updates its status, and insure that the email contains the ENCRYPTION: MUA
header, creating it if necessary. And it MUST do this at any stage in the
process. (not just upon submission). 

What this does in handle the case where there are two updated MTAs, but one in
the middle relaying is not, and some other errors or special cases.

The above is part of addressing the second problem, which is how we insure the
encypted status of an email is passed on between MTAs.

Here we may have a mixture of updated and non-updated MTAs. If the above rules
are followed, in the end, only the LAST MTA, the one that is delivering the
emails to local users, has to be updated. That last MTA is either going to have
the status passed to it by an updated MTA, or see an ENCRYPTION:MUA header, or
see a plussed address, in which case it will follow the rules and treat the
email as previously encrypted, also adding the header.

The net result of the above is that, for example, a business might only upgrade
THEIR MTA, and get the full anti-spam and other benefits of this system. So there
is an immediate benefit to the users even if no one else on the internet has
upgraded yet.

The actual MTA to MTA mail transaction is slightly tricky, as we need to be able
to accept or deny based upon the sender, and specifying the sender is the very
first transaction in an individual mail submission.

MAIL FROM:[email-masked]

So the status of whether a mail transaction is for an encrypted email needs to be
known before that point. Sendmail has a way to delay that check, but this is
configurable so cannot be counted on. So I think the way to go here is to use
PRECRYPTED as a mode that can be turned on or off. That would also make sending a
series of encrypted emails more efficient, since the command would only need to
be made once for the block of emails.

So we would be looking at something more like:

EHLO mail.example.com
220 Howdy there mail.example.com. uptodate-mail V2.1.0 ready for your command.
PRECYPTED ON
2xx OK Precrypted mode ON, expecting encrypted emails.
MAIL FROM:[email-masked]
250 Precrypted Sender OK
RCPT TO:[email-masked]
250 Recipient OK
...
PRECYPTED OFF
2xx OK Precrypted mode OFF expecting normal email
... send normal mail

I think I have most of the edge cases covered, but if not, the result would be
that an encrypted email is accepted, because the system thinks it is ordinary
mail. This can then be dealt with by normal filtering, which, while it may not
be able to read the email, should be at least able to recognize an encrypted
email, and dump it or otherwise do something sensible.

The final problem is the user must be able to communicate whitelists and/or
blacklists to the local receiving MTA. This gets pretty system and MTA specific.

As I previously mentioned, I doubt this will be much of a problem for large
services, since they already are storing loads of metadata in databases, etc.

For medium and small systems, it might to be useful to have a somewhat
standardized system. 

For unix style systems and sendmail (using this only because it is what I am
most familiar with) I might do something like this: Each user dir has a
.mailwhitelist and .mailblacklist file which just contains the raw email
addresses. In addition, there is one more file that is the result of putting
those lists into the specific format used by the specific MTA in use. So the
standarization here is: standard format whitelist and blacklist files (which
could also be used by another program, such as spamassassin or procmail), plus
an MTA dependent file in that MTAs proper format.

So for example with sendmail, it uses /etc/mail/access, so that file in the
userdir might be .access. In Sendmails case, what actualy happens is that the
access file is where the user puts blocks, etc, but that file must be compiled
into a database for actual use by the sendmail program, access.db. Often there
is a makefile or similar way that is updated, so the actual addition of the
local users whitelists to the main MTA list would be done by that makefile or
similar means.

In the actual access file itself, Sendmail would need to add the capability to
distinguish pre-encryped email in its rules. Currently, for normal email I
could make a default deny mode with something like:

To:[email-masked]    REJECT
From:[email-masked]     OK
From:[email-masked]    OK

which would allow me to receive only mail from those two users.

So maybe using something like:

To_Precrypted:[email-masked]    REJECT
From_Precrypted:[email-masked]     OK
From_Precrypted:[email-masked]    OK

would work well. And we may as well throw in Connect_Precrypted: as well, which
will allow for whitelisting by connecting address, domain, etc.

I mention above the users should have individual control of whitelists,
however, since this is primarily a spam control measure, that is probably not
really necessary in the sense of 'only my whitelist applies to me'. It does not
really matter if Mary in accounting has whitelisted [email-masked]',
since that person will not be a spammer, and will never email me anyway. If
they did, I would be unable to read the email since I would not have exchanged
keys with them. Normal mail filters could just drop it as well.

It is crytal clear that NSA and other state actors are treating encrypted email
differently, I even saw a comment by some senator to the effect that 'if you
are using encryption, you are proabably a terrorist or criminal'. So until
encryption is very commonly used, it might be said that 'Unless everyone has
privacy, no one does'.

It is not enough to just provide easy ways for people to use encryption, we
must actually get them to USE it. Even now, with all the revelations, something
like 40 percent of the people seem to not care that NSA etc are collecting,
analyzing, and possibly reading their emails.

What people pretty much universally DO care about is spam. So I think this is a
real sales point to get people to actually USE encryption: 'If you use
encryption, you will get NO spam to those accounts, plus have privacy.'

Something not really covered here is that I think there should be some guidelines
for MUAs concerning standardizing the interface to this. Standard names for
functions like adding someone as an encryption only person ('friend'), that MUAs
should have standard ways to handle key exchange, etc. But this message is way
too long already.

So what do you think? Good idea? Flaws to fix? Have a better idea to solve the
problem?

-Mike Demmers