2014-09-06

Response to Modern anti-spam and E2E crypto

This is a response to this email: https://moderncrypto.org/mail-archive/messaging/2014/000780.html?hn (I don't want to sign up to a mailing list just to send one reply, especially when I want it to be public).
If you haven't read the mail I suggest you at least skim it.
tl;dr: Spam fighting relies heavily on the provider being able to read emails plain text itself. The question is how to solve that problem in the case of "almost everyone uses end to end encryption".

It seems to me only the negative sides of end to end cryptography are seen. There is a lot it can do for us, maybe even eliminate spam altogether. Basically there are types of email we have to consider:

I have a friend (or any kind of person I somehow know directly) and want to exchange emails with him or her. Easy: I get my friends public key and tell my provider "I trust this public key, please let the mails through". He or she does the same. Done.

I have I company I want to receive mail from. It doesn't matter if I sign up with some social site or just want a receipt, I get the public key off their web site and do the same thing as above. If the company wants to receive answers from me I tell them my public key after account creation, which has to be shielded against spam account creation anyways.

The only difficult case is when I want to receive emails from addresses I don't know before. There are several sub cases here, which have different difficulties of solving the problem.

1. Company to company mails. Easy: Sign all mails with the company mail server and trust that key on the other company mail server.

2. Company to client mail. wait, since when do we want to receive mail from a company we don't know? Generally speaking, I wouldn't want to. In the small number of cases where I might want to, it would probably be ok to contact me another way first. Example: The local electricity company wants to send me the bill via email. If I don't know them since I moved to my appartment / house / whatever, they can send me a letter first and all is well. State emails are another thing, but there could be a general "This is a state mail" public key. I honestly can't think of any case where I would want to receive an email from a non-person-address I don't know and where a letter before wouldn't be the way to go.

3. Client to company mail. This is where it gets a little complicated. However there would still be the solution of "create account (CAPTCHA protected and whatnot), submit your key, done.

4. Person to Person. Someone reads a blog post and wants to reply to that on a personal level. Okay, this is the only case where I don't have a perfect solution in my mind. However until this case there are a lot of mails that got sent. Now we can talk about reputation on the provider end (how many accounts did not reject how many mails from this account), about web of trust (Would it not be awesome to let that "everyone knows everyone via 7 persons" mantra of social networking do the work for you?) and about friend requests. Yes, friend requests for emails, why the hell not? Key signing is just a technical way of expressing that (note: the word friend in "friend request" should not be read to literally). One can set rules as soft or as hard as one wants: Only one friend request per domain before one accepts any more mail? Or just "only a friend request per address before more mail to this account".

Yes I make it sound easy when it is a lot of work. But I say it's less work than plain text spam fighting.
Yes the client side tools are shitty. We need a lot of work to make that stuff usable. However it is entirely possible: Smartphones and qr codes make public key exchange easy. Add the email to the address book in the same function and it just got easier than before. We need good common APIs from email providers to send them keys we trust or do not trust anymore.
Yes, signing every mail outside of the encryption makes us horribly trackable. I don't have a perfect solution here, however not doing it isn't one either. As long as everything is sent from the same account it doesn't matter anyway. And there is always the possibility of the web of trust of self, where a different key is used for every email account, every contact, however you like it and where you can let all the keys trust each other secretly. Good keychain software is needed of course, but it is any case, if we ever want to bring end to end encryption to the masses and maybe solve the "I have to many passwords" problem on the way.

Please tell me if I have obvious flaws in my arguments, if I just overlooked some cases or if you have better ideas.