R E : Reliable Email

1. RE: Reliable Email Scott Garriss (CMU) Michael Kaminsky (Intel Research Pittsburgh) Michael Freedman (NYU/Stanford) Brad Karp (University College London) David Mazières (Stanford) Haifeng Yu (Intel Research Pittsburgh/CMU)

2. Motivation • Spam is a huge problem today • More than 65% of email traffic is spam. • Large investment by users/IT organizations ($2.5b in 2003 on increased server capacity) • But, more importantly…

3. Email is no longer reliable • Users can't say what they want any more • Ex: Intel job offer goes to spam folder • Ex: Discussion about spam filtering Goal:Improve email's reliability

4. Outline • Background / Related Work • Design • Social networks and Attestations • Preserving Privacy • Re: in Practice • Evaluation • Conclusion

5. Basic Terminology • False Positives (FP) • Legitimate email marked as spam • Can lose important mail • Email less reliable • False Negatives (FN) • Spam marked as legitimate email • Annoying and/or offensive

6. Incoming Mail Default Path Accept Default Path Reject Whitelist System RejectionSystem Inbox Spam A Typical Spam Defense System

7. Related Work • People use a variety of techniques • Content filters (SpamAssassin, Bayesian) • Payment/proof-of-work schemes • Sender verification • Blacklists • Human-based (collaborative) filtering • Whitelists Idea: Whitelist friends of friends Re: is complementary to existing systems.

8. Traditional Whitelist Systems Traditional WLs suffer from three problems: • Spammers can forge sender addresses Alice Bob From: Charlie

9. Traditional Whitelist Systems Use anti-forgery mechanism to handle (1), similar to existing techniques.Handle (2) with social networks Whitelist • Debby • Tom Traditional WLs suffer from three problems: • Spammers can forge sender addresses • Whitelists don’t help with strangers • Require manual effort Alice Bob From: Alice

10. Approach: Use Social Networks Accept! Bob (B) • Bob whitelists people he trusts • Bob signs attestation B→A • No one can forge attestations from Bob • Bob can share his attestations Attestation: B→AA is a friend of BB trusts A not to send him spam trust Alice (A)

11. Approach: Use Social Networks Accept? Bob (B) • What if sender & recipient are not friends? • Note that B→A and A→C • B trusts C because he's a friend-of-friend (FoF) FoF trust relationship trust trust Charlie (C) Alice (A)

12. Find FoFs: Attestation Servers Note: no changes to SMTP, incremental deployment Charlie (C) Bob (B) A→C Charlie’sAttestationServer (AS) Recipient (Bob) queries sender’s attestation server for mutual friends… Sharing attestations revealsyour correspondents!

13. Privacy Goals Charlie (C) • Email recipients never reveal their friends • Email senders only reveal specific friends queried for by recipients • Only users who have actually received mail from the sender can query the sender for attestations Bob (B) X X X B’s list of friends Charlie’s AS C’s list of friends FoF Query Debby

14. Outline • Background / Related Work • Design • Social networks and Attestations • Preserving Privacy • Re: in Practice • Evaluation • Conclusion

15. encrypted friends PM Encrypt PM Evaluate A→S A R→A C→S R→B B A→S A→S D→S C R→C encrypted mutual friends C→S mutual friends PM Decrypt C→S E→S ? ? ? ? Cryptographic Private Matching Sender (S)’s AS Recipient (R) friends friends

16. PM Details • First implementation & use of PM protocol • Based on our previous work [Freedman04] • Attestations encoded in encrypted polynomial • Uses Homomorphic Encryption • Ex: Paillier, ElGamal variant • enc(m1+m2) = enc(m1) ∙ enc(m2) • enc(c ∙ m1) = enc(m1)c

17. Restricting FoF Queries Signed authentication token • Sender can use token to restrict FoF query • Users have a public/secret key pair Sender (S) Recipient (R)

18. Restricting FoF Queries • Sender can use token to restrict FoF query • Users have a public/secret key pair • Recipient can use token to detect forgery Sender (S) Recipient (R) Sender’sAttestationServer (AS) FoF Query

19. Outline • Background / Related Work • Design • Social networks and Attestations • Preserving Privacy • Re: in Practice • Evaluation • Conclusion

20. Scenario 1: Valid Mail Rejected Alice Bob “mortgage... MailClient MailServer SpamAssassin

21. Scenario 2: Direct Acceptance Alice Bob Bob’s Friends • Alice • Tom “mortgage... MailClient MailServer Hit! auth.token Re: AttestationServer TokenOK SpamAssassin

22. Scenario 3: FoF Acceptance Charlie Bob Bob’s Friends • Alice • Tom MailServer MailClient “mortgage... auth. token & FoF query Re: AttestationServer No DirectHit token OK &E(?)E(Alice) Mutual friend:Alice Charlie is a friend of • John • Alice SpamAssassin

23. Outline • Background / Related Work • Design • Social networks and Attestations • Preserving Privacy • Re: in Practice • Evaluation • Conclusion

24. Evaluation • Accept almost 75% of received email • Prevent up to 88% of the false positives incurred by the existing spam filter • Augment friend relationships with FoF relationships increases the fraction of all received email accepted by RE: by at least 10%

25. Conclusion • Email is no longer reliable because of FPs Idea: Whitelist friends of friends • Preserve privacy using PM protocol • Opportunity for FoF whitelisting • Re: could eliminate up to 87% of real FPs • Acceptable performance cost