A Trust Overlay for Email Operations: DKIM and Beyond

1
A Trust Overlay for Email Operations DKIM and
Beyond

• Dave CrockerBrandenburg Internet
  Workingbbiw.net
• Apricot / Perth 2006

2
We all know the problem

• Bad Actors send spam, phishing, etc.
• Detecting them is a continuing battle
• We are stuck with a permanent arms race
• Existing tools are pretty good, but are not
  enough
• Need an effort to identify Good Actors
• They try to follow reasonable rules
• They fix problems, when they make errors

3
Trust Overlay

• Upgrade, without changing basic email
• Easy, open, direct communications still possible
• Permit spontaneous contact (no prior arrangement)
• Add special procedures for Good Actors
• Identify responsible participant
• If they conform to community standards, then
• Give their mail streamlined delivery processing

4
1. Identify Responsible Participant

• Types of identifiers
• IP Address of host or network operator
• Domain Name of user or operator
• Email address or author
• Responsible for
• Content The author
• Message stream An operator
• Viable choices today
• IP Address
• SPF, Sender-ID ()
• DKIM lthttp//dkim.orggt

5
2a. Community Standards

• Each receiver can have own preferences
• Tailor receive-side filtering criteria
• Independent third-parties create own set
• White-/Black- list services
• Broad community consensus
• Laws (well, maybe)
• Industry best practises (if we can agree)

6
2b. Conform to community standards

• Pre-receipt assessment
• Build the lists (accreditation, reputation)
• Receipt-time enforcement
• Integrate into filtering engine
• Add special flag to user-visible display of
  message
• Post-receipt correction
• Everyone makes mistakes, so compliance is an
  ongoing challenge

7
The Pieces of Trust
Message
ID / Signature Creation
Administrative Domain
Internet
Filter
ID / Key Query
ID / Signature Verification
Sender Signing Practices
Message
ID / Signer Evaluation
ok
Sender Assessment
not ok
Other Tests
Administrative Domain
8
DomainKeys Identified Mail (DKIM) Overview
lthttp//dkim.orggt

• Lets an organization take responsibility for a
  message
• Their reputation is basis for evaluating whether
  to deliver
• Adds digital signature to a message, associating
  it with a domain name

• Multi-vendor specification
• Derived from Yahoo DomainKeys and Cisco
  Identified Internet Mail
• Stable signing specs available now!
• Implementations, now!
• IETF working group(!)
• Refine and standardize

9
DKIM Goals

• Msg header authentication
• DNS identifiers
• Public keys in DNS
• End-to-end
• Between origin/receiver administrative domains.
• Not path-based

• Transparent to end users
• No client User Agent upgrades required
• But extensible to per-user
• Allow sender delegation
• Outsourcing
• Low development, deployment, use costs
• No new, trusted third parties (except DNS)

10
Technical High-points

• Signs body and selected parts of header
• Signature transmitted in DKIM-Signature header
• Public key stored in DNS
• In _domainkey subdomain
• New RR type planned, with fall-back to TXT
• Domain Names sub-divided using selectors
• Allows multiple keys for aging, delegation, etc.
• Sender Signing Practices
• Signer can publish its rules, such as requiring
  signing
• Allows lookup for missing or improper signature

11
DKIM-Signature header

• Example
• DKIM-Signature arsa-sha1 qdns
• dexample.com
• iuser_at_eng.example.com
• sjun2005.eng crelaxed/simple
• t1117574938 x1118006938
• hfromtosubjectdate
• bdzdVyOfAKCdLXdJOc9G2q8LoXSlEniSb
• avyuU4zGeeruD00lszZVoG4ZHRNiYzR
• DNS query will be made to
• jun2005.eng._domainkey.example.com

12
Status and Plea

• Deployment is happening (slowly)
• http//mipassoc.org/deploy
• Open source versions, with more coming
• DNS administration is difficult
• We hope to create tools to make it easier
• Plea(s)
• Please join http//mipassoc.org/supporters.html
  list
• Please try available versions
• Please encourage progress in IETF working group

13
Discussion
14
Deployment