Hadmut Danisch

hadmut@danisch.de

(IETF-Meeting Seoul) / Hadmut Danisch Slide 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

(IETF-Meeting Seoul) / Hadmut Danisch Slide 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

(IETF-Meeting Seoul) / Hadmut Danisch Slide 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?

(IETF-Meeting Seoul) / Hadmut Danisch Slide 5

Predecessor of RMX

• Developed since 1992 as 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

(IETF-Meeting Seoul) / Hadmut Danisch Slide 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?

(IETF-Meeting Seoul) / Hadmut Danisch Slide 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“

(IETF-Meeting Seoul) / Hadmut Danisch Slide 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)

(IETF-Meeting Seoul) / Hadmut Danisch Slide 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

(IETF-Meeting Seoul) / Hadmut Danisch Slide 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

(IETF-Meeting Seoul) / Hadmut Danisch Slide 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

(IETF-Meeting Seoul) / Hadmut Danisch Slide 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

(IETF-Meeting Seoul) / Hadmut Danisch Slide 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“

(IETF-Meeting Seoul) / Hadmut Danisch Slide 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!

(IETF-Meeting Seoul) / Hadmut Danisch Slide 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

(IETF-Meeting Seoul) / Hadmut Danisch Slide 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

(IETF-Meeting Seoul) / Hadmut Danisch Slide 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?

(IETF-Meeting Seoul) / Hadmut Danisch Slide 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 detectedYou‘re free to implement whatever you want!Impossible with DNS-based RMX, DMP, SPF,…

(IETF-Meeting Seoul) / Hadmut Danisch Slide 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)

(IETF-Meeting Seoul) / Hadmut Danisch Slide 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

(IETF-Meeting Seoul) / Hadmut Danisch Slide 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

(IETF-Meeting Seoul) / Hadmut Danisch Slide 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