Dr. David MacQuigg

1
Autonomic Trust System Verify Identity
and Assess Reputation

• Dr. David MacQuigg
• Research Associate
• Autonomic Computing Laboratory

University of Arizona ECE 509 November 2008
2

• The Problem with Trust on the Internet
• Spam problem, 20B/year, intractable
• Fraud and other serious crimes
• Non-technical factors are critical
• Modeling of Mail Handling Systems
• Actors, Agents, Terminology
• Roles and Responsibilites
• Trust Identity Reputation
• Identity (Authentication)
• IP-based (CSV, SPF, SenderID)
• Signatures (DKIM)
• Reputation
• Reputation/Accreditation Systems
• Registry of Internet Transmitters

3
Economics of Email Abuse

• 200B   annual benefit of email   20B   cost
  of abuse          100M users x (.25/day
  deleting spam 100/yr lost emails)    2B  
  benefit to anti-spam industry        
  100 companies x 20M/yr  0.2B   benefit to
  spammers          10K spammers x
  20K/yr  0.02B  cost of an effective
  authentication/reputation system        
  10M users x 2/yr          100K companies
  x 200/yr (90 internal, 10 external services)

4
Textbook Model of a Mail Handling System
Figure 9.1 Sequence of mail relays store and
forward email messages
Peterson Davie, Computer
Networks, 4th ed.
5
Real Mail Handling System
P. Faltstrom, mail-flows-0.4, Jan 6, 2004,
http//www.ripe.net/ripe/meetings/ripe-47/mailflow
s.pdf
6
Relay-Level Model
Function Modules and the Protocols used between
them
D. Crocker, "Internet Mail Architecture", 2008,
http//tools.ietf.org/html/draft-crocker-email-arc
h-10
7
Administrative-Level Model
------- -------
------- ADMD1
ADMD3 ADMD4 -----
----- -----
----------------------gt
User
-Edge-----gt-User
--------- ---gt V
ADMD2 -------
------- Edge----- -----
-------
-----Transit----
---------
D. Crocker, "Internet Mail Architecture", 2008,
http//tools.ietf.org/html/draft-crocker-email-arc
h-10
Administrative Management Domains (ADMD)
8
The Internet Today
9
Typical Mail Handling System ( a better textbook
model )
  --- Sender's Network ---           --
Recipient's Network -                           
       /  Author gt MSA/Transmitter --gt / --gt
Receiver/MDA gt Recipient                       
         /                             Border
10
Proposed Model for Mail Handling Systems
Simple Setup with four Actors --- Sender's
Network --- -- Recipient's Network
- / Author gt
MSA/Transmitter --gt / --gt Receiver/MDA gt
Recipient /
Border Actors, Roles and
Notation Actors include Users and Agents. Agents
may play more than one role, but no role has more
than one Actor. Typical roles include
Transmitting, Receiving, Forwarding, and
Delivery. A Border occurs when there is no prior
relationship between Agents. --gt Direction of
mail flow (no statement as to relationship) gt
Indirect relationship (e.g. both directly related
to Recipient) gt Direct relationship between
Actors (e.g. a contract) A/B Roles A and B both
played by the same Actor
11
Other Common Setups

• Simple Forwarding is quite common
• -------- Recipient's Network
  ---------
• /
• --gt / --gt Receiver/Forwarder gt MDA gt
  Recipient
• /
• Border
• Chain Forwarding should be discouraged
• ------------ Recipient's Network
  ------------
• /
• --gt / --gt Receiver gt Forwarder(s) gt MDA gt
  Recipient
• /
• Border
• Open Forwarding must be banned
• / / -- Recipient's
  Network -

12
Roles and Responsibilities

• Author
• - Originate messages
• - Provide a password or other means of
  authentication
• MSA - Mail Submission Agent
• - Authenticate the Author
• - Manage Author accounts
• Transmitter
• - Spam Prevention
• - rate limits, content analysis, alerts
• - respond to spam reports
• - maintain reputation
• - Authentication
• - RFC compliance
• - IP authorization (SPF, SID, CSV, ...)
• - signatures key management (DKIM ...)
• Receiver

13
Roles and Responsibilities (continued)

• Forwarder
• - Authenticate upstream Agent
• - Set up forwarding to downstream Agent
• - check RFC compliance
• - set up authentication records
• - submit forwarding request, wait for approval
• - Manage Recipient accounts
• - maintain database of forwarding addresses
• - suspend account when a message is rejected
• - communicate w Recipient re " "
• - Maintain reputation as a trusted Forwarder
• - certifications
• MDA - Mail Delivery Agent
• - Authenticate upstream Agent
• - Sort and store messages
• - Provide access for Recipients
• - POP3, IMAP, Webmail
• - Manage Recipient accounts/options

14
Identity Authenticating the Sender
SMTP makes Forgery Easy Forger
-------gt /
/ Author gt MSA/Transmitter --gt / --gt
Receiver/MDA gt Recipient /
/ / /
Border / /
/ -- Secure Channel --
TCP makes IP addresses (relatively) secure The
source address is real, but it may be only a
zombie! DNS offers a (relatively) secure
channel Domain owners can publish their
authorized addresses Or they can publish a public
key
15
Authentication Methods
Author gt MSA/Transmitter --gt / --gt
Receiver/MDA gt Recipient /
/ / /
Border / /
/ -- Secure Channel --
IP-based Authentication (SPF, SenderID, CSV)
Sender provides a list of authorized transmitter
addresses. Can be very efficient (no data
transfer). Signature-based Authentication
(DKIM) Sender provides a Public Key via a
secure channel. Messages are signed with the
related Private Key. End-to-end protocol can
be very secure, even with an un-trusted
Forwarder in the middle.
16
Reputation the other half of trust
Millions of legitimate senders are simply
unknown Aggregation of data is essential
Ground Up Gossip Top Down Proprietary
Systems Registry of Internet
Transmitters Some legitimate senders are not
qualified to operate a transmitter Make
outsourcing the Transmitter role
easy. Accountability is essential no excuses.
17
So why isnt it happening?

• Hurdles that trust systems must avoid or
  overcome,
• in order of decreasing severity
• Required simultaneous upgrades in software or
  setup (Flag Day)
• Required widespread adoption by Agents before any
  benefit is realized by Recipients (By June
  30th, all senders will ...)
• Required widespread adoption of one company's
  method or service (Microsoft patent)
• Changes that cause a temporary degradation in
  service
• ( loss of mail due to misconfigurations on
  the Receiver side )
• 5) Changes in current practicesa) A
  well-established and standards-compliant
  practice.b) A widespread but non-standardized
  practice. ("Misuse" of Return Address)c) A
  widespread but non-compliant practice. (bad HELO
  name)d) An already unacceptable practice. (open
  relays)
• 6) Lack of motivation
• a) Cant keep track of all their
  transmitter addresses
• b) Reversed incentives more spam more
  money

18
Suggested Receiver Setup
19
Analysis of SPF using our models

• Simple Forwarding
• -------- Recipient's Network
  ---------
• /
• --gt / --gt Receiver/Forwarder gt MDA gt
  Recipient
• /
• Border

SPF correlates the Return Address to the incoming
IP address. Forwarders are expected to re-write
the Return Address. Very few forwarders are doing
that. A misconfigured MDA sees the forwarded
message as forgery. The message is quarantined,
and possibly lost. Senders are avoiding the loss
by publishing neutral SPF records. Forwarders
will not change until senders demand it. SPF is
stuck.
20
Bibliography
A short list of the most useful books and
articles on the technology underlying email.

• TCP/IP Illustrated, vol. I, The Protocols, W.
  Richard Stevens, 1994. Very thorough, yet
  readable. Good illustrations.
• Computer Networks, Peterson Davie, 4th ed.
  good on all relevant technologies except email.
• "Internet Mail Architecture", D. Crocker,
  http//www.ietf.org/internet-drafts/draft-crocker-
  email-arch-11.txt (work in progress) - best
  overview with references to all the relevant RFC
  standards.
• Pro DNS and BIND, Ron Aitchison, Apress 2005.
  Very readable book on the Domain Name System.
• "CircleID", http//www.circleid.com a
  "Collaborative Intelligence Hub for the
  Internet's Core Infrastructure Policies"
  current articles by top industry experts.
• Project Links
• https//www.open-mail.org current status of our
  Identity and Reputation System
• http//purl.net/macquigg/email articles and
  notes from early development.

21
Identities in an Email Session
telnet open-mail.org 25 220 open-mail.org ESMTP
Sendmail 8.13.1/8.13.1 Wed, 30 Aug 2006 073642
-0400 HELO mailout1.phrednet.com 250
open-mail.org Hello ip068.subnet71.gci-net.com
216.183.71.68, pleased to meet you MAIL
FROMltmacquigg_at_box67.comgt 250 2.1.0
ltmacquigg_at_box67.comgt... Sender ok RCPT
TOltjman_at_box67.comgt 250 2.1.5 ltjman_at_box67.comgt...
Recipient ok DATA 354 Enter mail, end with "." on
a line by itself From Dave\r\nTo Test
Recipient\r\nSubject SPAM SPAM SPAM\r\n\r\nThis
is message 1 from our test script.\r\n.\r\n 250
2.0.0 k7TKIBYb024731 Message accepted for
delivery QUIT 221 2.0.0 open-mail.org closing
connection
1
2
6 Network Owner
3
4
RFC-2821 Helo Name Envelope Addresses Return
Address Recipient Addresses
RFC-2822 Header Addresses From Address
Reply-To Address
1
4
2
5
3