Re: [Endymail] spam versus cleartext

Sent from my iPhone

> On Sep 7, 2014, at 10:09 AM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
> 
>> On Sun, Sep 7, 2014 at 9:21 AM, Pete Resnick <presnick@qti.qualcomm.com> 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.
It seems the point of the original posting may have been lost.  Folks are jumping right back to solution design instead of thinking through operational costs of various approaches.  How does handing not only spam, but other attack like phishing and spear phishing evolve when e2e messaging is the norm?  We may have increased privacy, but have we helped the attacker?  End points/users can't address these and other attacks on their own.  We need to think through operational practices and try to understand how changes will effect these practices to then influence what design choices make sense.

> 
> 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 <bob@example.com>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).
> 

If anyone can search for a key, spammers and spear phishing attackers have this capability too.

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

What happens when Alice's email is compromised?  This is a common tactic today and may only increase with e2e.

I'm not arguing against e2e, but rather that we think through the effect changes will have understanding today's operational and security/incident response practices.

Best regards,
Kathleen 

> 
> 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
> Endymail@ietf.org
> https://www.ietf.org/mailman/listinfo/endymail