On Sun, Sep 7, 2014 at 9:21 AM, Pete Resnick <[email protected]> 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 <[email protected]>, 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. _______________________________________________ Endymail mailing list [email protected] https://www.ietf.org/mailman/listinfo/endymail
