Re: [Endymail] spam versus cleartext

[Phillip Hallam-Baker <[e-mail]>]

On Sun, Sep 7, 2014 at 9:21 AM, Pete Resnick <[e-mail]> wrote:
> On 9/6/14 3:38 AM, Eliot Lear wrote:
>>
>> In the early days fo perpass we had lengthy discussions about the
>> tension between privacy and ability of security systems to reduce spam.
>> Below is an article from a gentleman who used to work at Google, which I
>> thought this group might find interesting.
>>
>> https://moderncrypto.org/mail-archive/messaging/2014/000780.html
>>
>
>
> Along similar lines to what John Levine said,: Obviously doing e2e crypto
> gets you signatures. Since we are blue-skying here, I think it is perfectly
> plausible to say, "If you want to send me e2e encrypted messages, you also
> have to send me signed messages, and you don't or your signature is not in
> my contacts list already, your encrypted mail is going to bounce." I think
> it's possible that in the fullness of time, many users go to a contact-list
> model of email (a la IM) where the mail simply bounces unless it has a
> signature that is already in the contacts list.


I think that is right, but not the whole picture.

I see endymail as a subset of mail. All mail should be encrypted at
the message layer but only whitelisted mail would be e2e encrypted.

This can be done automatically as follows:


A) Some sort of discovery infrastructure maps email addresses to key hashes.
B) Some sort of discovery infrastructure maps key hashes to keys.
C) Inbound mail server has an encryption key
D) User has an endymail encryption key.


1) Alice sends a message to Bob <[e-mail]>om>, she doesn't know him yet.

Alice's email client uses infrastructure A and B to pull the best
public data for bob. This turns out to be a domain level record with
the mail server key (C).

Mail is opportunistically encrypted under the mail server key (C).
Mail server decrypts then (optional) re-encrypts message for delivery
to Bob.

The sent mail includes a header with Alice's encryption key
fingerprint. It is signed using either DKIM or S/MIME depending on the
settings specified in the key record.


2) Bob receives message

2a) Bob reads message hits the 'spam' key
2b) Bob reads message, does nothing
2c) Bob replies to message

Only 2c is going to result in Bob's client whitelisting Alice. His
response contains the key fingerprint that Bob needs to perform
retrieval of the key using infrastructure B.


3) Alice sends another message to Bob after his reply

Client notes that it is whitelisted and pulls the key from infrastructure B.


Note:

1) This whole process is completely frictionless. Neither Alice nor
Bob has to do anything differently.

2) This is only one point on the security spectrum. In other
applications we might allow easier access to the endy key or might not
allow access at all.

3) The reason for decoupling the key from the system via a key hash is
that it enables key rollover.


One question left open in the above is how we prevent the use of
infrastructure A as a means to obtain email addresses.

I am currently working on efficient ways to do that.