Prevention of Mail Forgery with RMX Approach

1. Hadmut Danisch hadmut@danisch.de

2. The problem: Mail Forgery • Tons of spam e-mails • Tons of worm e-mails • Fraudulent e-mails • Address spoofing against address based permissions (e.g. mailing lists) • Identity theft • DoS-Attacks through error messages sent to the wrong sender

3. Why not use Cryptography? • Not allowed in all legislations • Too complicated and error-prone for the masses • Too much overhead • Secrets to be stored on many insecure machines → Whole system compromised • Abuse of stolen keys difficult to detect • Even after >20 years of PKC still no common Infrastructure and PKI → Organizational Security is the better choice

4. Why not use Content Filters? • Spammers adapt • False positives when to tight • Can be (and has been) abused for violating freedom of speech • Can become „big brother‘s“ favourite tool • Works for self-redistributing worms, but not for Spam: Filters are too „late“. • Worms contain malicious code that can be analyzed and detected. • But what exactly is spam?

5. Predecessor of RMX • Developed since 1992as Research on Organizational Security • Database with authorization records:- Sender Address/IP patterns → Anti-Spoof- Recipient Address/IP patterns → Anti-Relay- Subject / IP patterns → Anti-Worm/Virus- Recipient/SMTP-Routing → Anti-DNS-Spoof • Sendmail ruleset as Interpreter • Simple Form of Application Level Firewall

6. Abuse of my domain danisch.de • In 1999-2001 my domain danisch.de was heavily abused as spam sender address • Up to >>100 complaints daily • How do I automatedly tell the world that the senders were not authorized to use danisch.de? • How can I publish my authorization records for public use?

7. The RMX approach: • Implicit protection against IP spoofing by TCP sequence numbers (weak, but sufficient) • Domain owners publish authorization records: Who is authorized to use their domain? • Receiving MTAs can use the record to verify whether sender is authorized • A kind of „Reverse MX“

8. RMX: DNS as a Public „Database“ • Compact encoding of rules in new RR type • Ordered list of authorization entries- IPv4/6 addresses and ranges- DNS name referrals (e.g. to DynDNS)- Domain members (reverse DNS)- APL referrals (RFC 3123)(see draft for further types and proposals)

9. RMX History • Predecessor since 1992 • RMX Draft 00: December 2002 • March 1st 2003: First posting of ASRG • RMX Draft 01: April 2003 • RMX Draft 02: June 2003 • RMX Draft 03: October 2003 • SCAF Draft 00: January 2004 • Dynamic/HTTP proposal: February 2004

10. „Me too“-derivatives The unpleasant side effect: • Lots of „derivatives“ • Very little technical differences • …but big marketing hype • US press notices US-made derivatives only, e.g. SPF and MS CallerID but ignores the original

11. Is DNS a good choice? No! • Records will often exceed DNS UDP size limit • Alternative TXT records even larger • Multi-user domains might require extreme update rates • Static records only • Always reveal mail relay structure • Impossible to refresh before expiry • Inconsistencies with multiple TXT records • Sometimes changes possible through ISP only • No standardized upload protocol • Not all secondaries allow change notification

12. A flaw of static records • German computer magazine c‘t just published: Virus and Worm authors are hijacking tens of thousands computers and turn them into spam-relays for money • Rent-a-spam army • DNS-based RMX, DMP, SPF,… comp-letely fail if infected machine is authorized • Dynamic Auth. can detect and protect

13. What is „Dynamic Authorization“? • Query a server which can run a program to generate a record on request • Three options:- Get a static authorization record- Get a dynamically generated record- Or pass params (Sender Address, IP Address, Recipient, MessageID,cookie,…) to the server and wait for „Yes“ or „No“

14. How to do it if not with DNS? • Use default pattern for URL • Option: URL pattern in TXT record • Use DNS (A/SRV) only to find the server • Macro substitution applied to URL pattern • Pass Params as CGI params in URL • Supports all three methods of Authorization with a single access method!

15. URL as Auth.-Record Locator • Extensible: Open for future protocols • Supports:- HTTP, HTTPS- LDAP- DNS (if still wanted) • Don‘t stick to today‘s DNS! • Keep it open for future extensions

16. Why HTTP to fetch the record • Plenty of HTTP servers • HTTPS • Easy implementation as file or CGI • HTTP Caches and expiry control • Domain can completely hide policy in CGI • Hidden delegation and referrals • Real time forgery detection in CGI • Any format: Lines, ASN.1, XML,… • Can use full sender e-mail address • MessID/Recipient/Subject/Date/… as params

17. Format of Authorization Records? • RMX RR encoding ? • Simple Text line ? • Multi-line Text ? • ASN.1/DER ? • XML ? • A program to evaluate? Java, Javascript ? • „Yes“ / „No“ for dynamic Authorization?

18. Policy Examples for DynAuth • Limit to 30 mails/day • Limit to 5 mail rejects a day • Limit to 5 mails to unknown recipients • Limit to 3 mails after business hours • Mails with special cookie only • User can send from same machine only • Immediate alert when fraud detected You‘re free to implement whatever you want! Impossible with DNS-based RMX, DMP, SPF,…

19. Still want to use Cryptography? • Cryptography is not suitable for world wide use for several reasons • But some do have a local X.509 PKI • Please discuss: Should mail be accepted if crypt. signed? • Authorization record could contain fingerprint of top CA (and maybe CRL)

20. Simple Caller Authoriz. Framework • Spam/Fraud/Spoofing not limited to e-mail • Use it as a general purpose mechanism, e.g. for News, Instant Message, P2P • New simple lightweight authorization mechanism for HTTP, FTP, LDAP, … • Different backends: Fetch auth records from HTTP, LDAP, (DNS),… • See draft-danisch-scaf-00.txt

21. Will this stop spam? Not yet! • It will stop address forgery • Now you will know who sent the spam.So what? • Spammers buy domains anonymously • Spammers have 365 domains/year • Spammers reside in foreign countries • Spammers change their name • Front men as domain owners

22. So what else will it take? • Correct and standardized whois entries • Blacklisting of spammer-friendly TLDs, countries, domain registrars, domain owners • Outlaw spam, penalties