1. A Trust Overlay for Email Operations: DKIM and Beyond Dave Crocker Brandenburg Internet Working bbiw.net Apricot / Perth 2006 Dave Crocker Brandenburg Internet Working bbiw.net Apricot / Perth 2006

2. 2 2 D. CrockerApricot 2006 / Trust Overlay 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  “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. 3 3 D. CrockerApricot 2006 / Trust Overlay 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 1. Identify “responsible” participant 2. If they conform to community standards, then… 3. Give their mail “streamlined” delivery processing  Upgrade, without changing basic email  Easy, open, direct communications still possible  Permit spontaneous contact (no prior arrangement)  Add special procedures for Good Actors 1. Identify “responsible” participant 2. If they conform to community standards, then… 3. Give their mail “streamlined” delivery processing

4. 4 4 D. CrockerApricot 2006 / Trust Overlay 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  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

5. 5 5 D. CrockerApricot 2006 / Trust Overlay 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)  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. 6 6 D. CrockerApricot 2006 / Trust Overlay 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  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. 7 7 D. CrockerApricot 2006 / Trust Overlay Filter The Pieces of Trust ID / Signature Verification ID / Signature Creation ID / Signer Evaluation ID / Key Query Sender Signing Practices Sender Assessment MessageMessage MessageMessage Internet Administrative Domain Other Tests ok not ok

8. 8 8 DomainKeys Identified Mail (DKIM) Overview: DomainKeys Identified Mail (DKIM) Overview:  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  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. 9 9 D. CrockerApricot 2006 / Trust Overlay DKIM Goals  Msg header authentication  DNS identifiers  Public keys in DNS  End-to-end  Between origin/receiver administrative domains.  Not path-based  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. 10 D. CrockerApricot 2006 / Trust Overlay 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  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. 11 D. CrockerApricot 2006 / Trust Overlay DKIM-Signature header  Example: DKIM-Signature: a=rsa-sha1; q=dns; d=example.com; i=user@eng.example.com; s=jun2005.eng; c=relaxed/simple; t=1117574938; x=1118006938; h=from:to:subject:date; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSb av+yuU4zGeeruD00lszZVoG4ZHRNiYzR  DNS query will be made to: _domainkey jun2005.eng._domainkey.example.com  Example: DKIM-Signature: a=rsa-sha1; q=dns; d=example.com; i=user@eng.example.com; s=jun2005.eng; c=relaxed/simple; t=1117574938; x=1118006938; h=from:to:subject:date; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSb av+yuU4zGeeruD00lszZVoG4ZHRNiYzR  DNS query will be made to: _domainkey jun2005.eng._domainkey.example.com

12. 12 D. CrockerApricot 2006 / Trust Overlay Status and Plea  Deployment is happening (slowly)  http://mipassoc.org/deploy 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 listhttp://mipassoc.org/supporters.html  Please try available versions  Please encourage progress in IETF working group  Deployment is happening (slowly)  http://mipassoc.org/deploy 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 listhttp://mipassoc.org/supporters.html  Please try available versions  Please encourage progress in IETF working group

13. 13 D. CrockerApricot 2006 / Trust Overlay Discussion…Discussion…

14. 14 D. CrockerApricot 2006 / Trust Overlay DeploymentDeployment