draft-ietf-dkim-ssp-07.txt   draft-ietf-dkim-ssp-08.txt 
Network Working Group E. Allman Network Working Group E. Allman
Internet-Draft Sendmail, Inc. Internet-Draft Sendmail, Inc.
Intended status: Standards Track J. Fenton Intended status: Standards Track J. Fenton
Expires: May 26, 2009 Cisco Systems, Inc. Expires: June 20, 2009 Cisco Systems, Inc.
M. Delany M. Delany
Yahoo! Inc. Yahoo! Inc.
J. Levine J. Levine
Taughannock Networks Taughannock Networks
November 22, 2008 December 17, 2008
DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)
draft-ietf-dkim-ssp-07 draft-ietf-dkim-ssp-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 26, 2009. This Internet-Draft will expire on June 20, 2009.
Abstract Abstract
DomainKeys Identified Mail (DKIM) defines a domain-level DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email to permit verification of the authentication framework for email to permit verification of the
source and contents of messages. This document specifies an adjunct source and contents of messages. This document specifies an adjunct
mechanism to aid in assessing messages that do not contain a DKIM mechanism to aid in assessing messages that do not contain a DKIM
signature for the domain used in the author's address. It defines a signature for the domain used in the author's address. It defines a
record that can advertise whether a domain signs its outgoing mail, record that can advertise whether a domain signs its outgoing mail,
and how other hosts can access that record. and how other hosts can access that record.
skipping to change at page 2, line 29 skipping to change at page 2, line 29
3.3. ADSP Results . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. ADSP Results . . . . . . . . . . . . . . . . . . . . . . . 7
4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 7 4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 7
4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 7 4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 7
4.2. Publication of ADSP Records . . . . . . . . . . . . . . . 8 4.2. Publication of ADSP Records . . . . . . . . . . . . . . . 8
4.3. ADSP Lookup Procedure . . . . . . . . . . . . . . . . . . 8 4.3. ADSP Lookup Procedure . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.1. ADSP Specification Tag Registry . . . . . . . . . . . . . 10 5.1. ADSP Specification Tag Registry . . . . . . . . . . . . . 10
5.2. ADSP Outbound Signing Practices Registry . . . . . . . . . 10 5.2. ADSP Outbound Signing Practices Registry . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6.1. ADSP Threat Model . . . . . . . . . . . . . . . . . . . . 11 6.1. ADSP Threat Model . . . . . . . . . . . . . . . . . . . . 11
6.2. DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. DNS Considerations . . . . . . . . . . . . . . . . . . . . 12
6.3. DNS Wildcards . . . . . . . . . . . . . . . . . . . . . . 12 6.3. DNS Wildcards . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. References - Normative . . . . . . . . . . . . . . . . . . 13 7.1. References - Normative . . . . . . . . . . . . . . . . . . 13
7.2. References - Informative . . . . . . . . . . . . . . . . . 13 7.2. References - Informative . . . . . . . . . . . . . . . . . 13
Appendix A. Lookup Examples . . . . . . . . . . . . . . . . . . . 13 Appendix A. Lookup Examples . . . . . . . . . . . . . . . . . . . 13
A.1. Domain and ADSP exist . . . . . . . . . . . . . . . . . . 14 A.1. Domain and ADSP exist . . . . . . . . . . . . . . . . . . 14
A.2. Domain exists, ADSP does not exist . . . . . . . . . . . . 14 A.2. Domain exists, ADSP does not exist . . . . . . . . . . . . 14
A.3. Domain does not exist . . . . . . . . . . . . . . . . . . 14 A.3. Domain does not exist . . . . . . . . . . . . . . . . . . 14
Appendix B. Usage Examples . . . . . . . . . . . . . . . . . . . 15 Appendix B. Usage Examples . . . . . . . . . . . . . . . . . . . 15
B.1. Single Location Domains . . . . . . . . . . . . . . . . . 15 B.1. Single Location Domains . . . . . . . . . . . . . . . . . 15
B.2. Bulk Mailing Domains . . . . . . . . . . . . . . . . . . . 15 B.2. Bulk Mailing Domains . . . . . . . . . . . . . . . . . . . 15
B.3. Bulk Mailing Domains with Discardable Mail . . . . . . . . 16 B.3. Bulk Mailing Domains with Discardable Mail . . . . . . . . 16
B.4. Third Party Senders . . . . . . . . . . . . . . . . . . . 16 B.4. Third Party Senders . . . . . . . . . . . . . . . . . . . 16
B.5. Domains with Independent Users and Liberal Use Policies . 16 B.5. Domains with Independent Users and Liberal Use Policies . 16
B.6. Non-email Domains . . . . . . . . . . . . . . . . . . . . 16 B.6. Non-email Domains . . . . . . . . . . . . . . . . . . . . 16
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 17 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 17
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 17 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 17
D.1. Changes since -ietf-dkim-06 . . . . . . . . . . . . . . . 17 D.1. Changes since -ietf-dkim-07 . . . . . . . . . . . . . . . 17
D.2. Changes since -ietf-dkim-05 . . . . . . . . . . . . . . . 17 D.2. Changes since -ietf-dkim-06 . . . . . . . . . . . . . . . 17
D.3. Changes since -ietf-dkim-04 . . . . . . . . . . . . . . . 17 D.3. Changes since -ietf-dkim-05 . . . . . . . . . . . . . . . 17
D.4. Changes since -ietf-dkim-03 . . . . . . . . . . . . . . . 18 D.4. Changes since -ietf-dkim-04 . . . . . . . . . . . . . . . 17
D.5. Changes since -ietf-dkim-02 . . . . . . . . . . . . . . . 18 D.5. Changes since -ietf-dkim-03 . . . . . . . . . . . . . . . 18
D.6. Changes since -ietf-dkim-ssp-01 . . . . . . . . . . . . . 19 D.6. Changes since -ietf-dkim-02 . . . . . . . . . . . . . . . 19
D.7. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 20 D.7. Changes since -ietf-dkim-ssp-01 . . . . . . . . . . . . . 19
D.8. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 21 D.8. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 20
D.9. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 21 D.9. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 21
D.10. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 21 D.10. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 21
D.11. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 23
1. Introduction 1. Introduction
DomainKeys Identified Mail (DKIM) defines a mechanism by which email DomainKeys Identified Mail (DKIM) defines a mechanism by which email
messages can be cryptographically signed, permitting a signing domain messages can be cryptographically signed, permitting a signing domain
to claim responsibility for the introduction of a message into the to claim responsibility for the introduction of a message into the
mail stream. Message recipients can verify the signature by querying mail stream. Message recipients can verify the signature by querying
the signer's domain directly to retrieve the appropriate public key, the signer's domain directly to retrieve the appropriate public key,
skipping to change at page 7, line 41 skipping to change at page 7, line 41
4. Detailed Description 4. Detailed Description
4.1. DNS Representation 4.1. DNS Representation
ADSP records are published using the DNS TXT resource record type. ADSP records are published using the DNS TXT resource record type.
The RDATA for ADSP resource records is textual in format, with The RDATA for ADSP resource records is textual in format, with
specific syntax and semantics relating to their role in describing specific syntax and semantics relating to their role in describing
ADSP. The "Tag=Value List" syntax described in section 3.2 of ADSP. The "Tag=Value List" syntax described in section 3.2 of
[RFC4871] is used. Records not in compliance with that syntax or the [RFC4871] is used, modified to use WSP rather than FWS. Records not
syntax of individual tags described in Section 4.3 MUST be ignored in compliance with that syntax or the syntax of individual tags
(considered equivalent to a NODATA result) for purposes of ADSP, described in Section 4.3 MUST be ignored (considered equivalent to a
although they MAY cause the logging of warning messages via an NODATA result) for purposes of ADSP, although they MAY cause the
appropriate system logging mechanism. If the RDATA contains multiple logging of warning messages via an appropriate system logging
character strings, the strings are logically concatenated with no mechanism. If the RDATA contains multiple character strings, the
delimiters between the strings. strings are logically concatenated with no delimiters between the
strings.
Note: ADSP changes the "Tag=Value List" syntax from [RFC4871] to Note: ADSP changes the "Tag=Value List" syntax from [RFC4871] to
use WSP rather than FWS in its DNS records. Domains MUST NOT use WSP rather than FWS in its DNS records. Domains MUST NOT
publish ADSP records with wildcard names. Wildcards within a publish ADSP records with wildcard names. Wildcards within a
domain publishing ADSP records pose a particular problem, as domain publishing ADSP records pose a particular problem, as
discussed in more detail in Section 6.3. discussed in more detail in Section 6.3.
4.2. Publication of ADSP Records 4.2. Publication of ADSP Records
ADSP is intended to apply to all mail sent using the domain name ADSP is intended to apply to all mail sent using the domain name
string of an Alleged Author. string of an Alleged Author.
4.2.1. Record Syntax 4.2.1. Record Syntax
ADSP records use the "tag=value" syntax described in section 3.2 of ADSP records use the "tag=value" syntax described in section 3.2 of
[RFC4871]. Every ADSP record MUST start with an outbound signing [RFC4871], modified to use WSP rather than FWS. Every ADSP record
practices tag, so the first four characters of the record are lower MUST start with an outbound signing practices tag, so the first four
case "dkim", followed by optional whitespace and "=". . characters of the record are lower case "dkim", followed by optional
whitespace and "=".
Tags used in ADSP records are described below. Unrecognized tags Tags used in ADSP records are described below. Unrecognized tags
MUST be ignored. In the ABNF below, the WSP token, and the ALPHA and MUST be ignored. In the ABNF below, the WSP token, and the ALPHA and
DIGIT tokens are imported from [RFC5234]. DIGIT tokens are imported from [RFC5234].
dkim= Outbound signing practices for the domain (plain-text; dkim= Outbound signing practices for the domain (plain-text;
REQUIRED). Possible values are as follows: REQUIRED). Possible values are as follows:
unknown The domain might sign some or all email. unknown The domain might sign some or all email.
skipping to change at page 12, line 13 skipping to change at page 12, line 13
treating the message differently during the delivery process or by treating the message differently during the delivery process or by
showing some indicator to the end recipient. Such a system is out of showing some indicator to the end recipient. Such a system is out of
scope for this specification. scope for this specification.
ADSP checkers may perform multiple DNS lookups per Alleged Author ADSP checkers may perform multiple DNS lookups per Alleged Author
Domain. Since these lookups are driven by domain names in email Domain. Since these lookups are driven by domain names in email
message headers of possibly fraudulent email, legitimate ADSP message headers of possibly fraudulent email, legitimate ADSP
checkers can become participants in traffic multiplication attacks on checkers can become participants in traffic multiplication attacks on
domains that appear in fraudulent email. domains that appear in fraudulent email.
6.2. DNS Attacks 6.2. DNS Considerations
An attacker might attack the DNS infrastructure in an attempt to An attacker might attack the DNS infrastructure in an attempt to
impersonate ADSP records to influence a receiver's decision on how it impersonate ADSP records to influence a receiver's decision on how it
will handle mail. However, such an attacker is more likely to attack will handle mail. However, such an attacker is more likely to attack
at a higher level, e.g., redirecting A or MX record lookups in order at a higher level, e.g., redirecting A or MX record lookups in order
to capture traffic that was legitimately intended for the target to capture traffic that was legitimately intended for the target
domain. These DNS security issues are addressed by DNSSEC [RFC4033]. domain. These DNS security issues are addressed by DNSSEC [RFC4033].
Because ADSP operates within the framework of the legacy e-mail Because ADSP operates within the framework of the legacy e-mail
system, the default result in the absence of an ADSP record is that system, the default result in the absence of an ADSP record is that
skipping to change at page 17, line 16 skipping to change at page 17, line 16
This document greatly benefited from comments by Steve Atkins, Jon This document greatly benefited from comments by Steve Atkins, Jon
Callas, Dave Crocker, JD Falk, Arvel Hathcock, Ellen Siegel, Michael Callas, Dave Crocker, JD Falk, Arvel Hathcock, Ellen Siegel, Michael
Thomas, and Wietse Venema. Thomas, and Wietse Venema.
Appendix D. Change Log Appendix D. Change Log
*NOTE TO RFC EDITOR: This section may be removed upon publication of *NOTE TO RFC EDITOR: This section may be removed upon publication of
this document as an RFC.* this document as an RFC.*
D.1. Changes since -ietf-dkim-06 D.1. Changes since -ietf-dkim-07
Clarify that ADSP records use WSP rather than FWS in 4.1 and 4.2.1.
D.2. Changes since -ietf-dkim-06
Minor editorial changes suggested by AD: Minor editorial changes suggested by AD:
o expand DKIM in title o expand DKIM in title
o clarify that there's no subdomain matching in Section 3.1 o clarify that there's no subdomain matching in Section 3.1
o ADSP lookup can terminate without a result if the DNS lookup fails o ADSP lookup can terminate without a result if the DNS lookup fails
o random dkim= values are treated as unknown o random dkim= values are treated as unknown
skipping to change at page 17, line 38 skipping to change at page 17, line 42
o in 4.2 note WSP not FWS o in 4.2 note WSP not FWS
o in 4.3 note that NODATA is not NXDOMAIN o in 4.3 note that NODATA is not NXDOMAIN
o add new Appendix A with lookup examples o add new Appendix A with lookup examples
Also address Tony's nits in Also address Tony's nits in
http://mipassoc.org/pipermail/ietf-dkim/2008q3/010720.html. Make the http://mipassoc.org/pipermail/ietf-dkim/2008q3/010720.html. Make the
examples consistently use the .example domain. examples consistently use the .example domain.
D.2. Changes since -ietf-dkim-05 D.3. Changes since -ietf-dkim-05
Minor editorial nits: define NOERROR, SERVFAIL, NXDOMAIN as rfc1035 Minor editorial nits: define NOERROR, SERVFAIL, NXDOMAIN as rfc1035
rcodes, change some punctuation, IANA section change IETF Consensus rcodes, change some punctuation, IANA section change IETF Consensus
to the new IETF Review. to the new IETF Review.
D.3. Changes since -ietf-dkim-04 D.4. Changes since -ietf-dkim-04
o Require dkim at the front of each record. o Require dkim at the front of each record.
o Disparage wildcard records. o Disparage wildcard records.
o Changed ABNF use of whitespace from FWS back to WSP, dkim-base is o Changed ABNF use of whitespace from FWS back to WSP, dkim-base is
wrong. wrong.
o RFC 2434 -> 5226, make ref to 4686 informational since it's not o RFC 2434 -> 5226, make ref to 4686 informational since it's not
standards track. standards track.
o Improve examples with material from Ellen. o Improve examples with material from Ellen.
D.4. Changes since -ietf-dkim-03 D.5. Changes since -ietf-dkim-03
o Name change for title and filename, to be ADSP o Name change for title and filename, to be ADSP
o String changes throughout, to author Domain signing practices and o String changes throughout, to author Domain signing practices and
to aDsp. to aDsp.
o Added some keywords. o Added some keywords.
o Clarified comparison of local part and domain in Author Address. o Clarified comparison of local part and domain in Author Address.
skipping to change at page 18, line 46 skipping to change at page 19, line 5
o Revised wildcard text. o Revised wildcard text.
o Removed 't' tag. o Removed 't' tag.
o Removed ADSP Flags Registry section. o Removed ADSP Flags Registry section.
o Changed ABNF use of whitespace from WSP back to FWS, for o Changed ABNF use of whitespace from WSP back to FWS, for
consistency with dkim-base. consistency with dkim-base.
D.5. Changes since -ietf-dkim-02 D.6. Changes since -ietf-dkim-02
o Merge in more text from ADSP draft. o Merge in more text from ADSP draft.
o Phrase actions as host's rather than checker. o Phrase actions as host's rather than checker.
o Explanatory description of i= matching. o Explanatory description of i= matching.
o Lookup procedure consistently refers to one ADSP record per o Lookup procedure consistently refers to one ADSP record per
lookup. lookup.
skipping to change at page 19, line 21 skipping to change at page 19, line 27
o Simplify imports of terms from other RFCs, add Local-part, 4234 -> o Simplify imports of terms from other RFCs, add Local-part, 4234 ->
5234. 5234.
o Add usage example appendix. o Add usage example appendix.
o Add IANA considerations. o Add IANA considerations.
o Update authors list o Update authors list
D.6. Changes since -ietf-dkim-ssp-01 D.7. Changes since -ietf-dkim-ssp-01
o Reworded introduction for clarity. o Reworded introduction for clarity.
o Various definition clarifications. o Various definition clarifications.
o Changed names of practices to unknown, all, and discardable. o Changed names of practices to unknown, all, and discardable.
o Removed normative language mandating use of SSP in particular o Removed normative language mandating use of SSP in particular
situations (issue 1538). situations (issue 1538).
skipping to change at page 20, line 22 skipping to change at page 20, line 27
o Introduced the concepts of "SSP Checker" and "Evaluator". o Introduced the concepts of "SSP Checker" and "Evaluator".
o Multiple author case now handled my separate invocations of SSP o Multiple author case now handled my separate invocations of SSP
checker by Evaluator (issue 1525). checker by Evaluator (issue 1525).
o Removed check to avoid querying top-level domains. o Removed check to avoid querying top-level domains.
o Changed ABNF use of whitespace from [FWS] to *WSP (partially o Changed ABNF use of whitespace from [FWS] to *WSP (partially
addresses issue 1543). addresses issue 1543).
D.7. Changes since -ietf-dkim-ssp-00 D.8. Changes since -ietf-dkim-ssp-00
o Clarified Operation Overview and eliminated use of Legitimate as o Clarified Operation Overview and eliminated use of Legitimate as
the counterpart of Suspicious since the words have different the counterpart of Suspicious since the words have different
meanings. meanings.
o Improved discussion (courtesy of Arvel Hathcock) of the use of TXT o Improved discussion (courtesy of Arvel Hathcock) of the use of TXT
records in DNS vs. a new RR type. records in DNS vs. a new RR type.
o Clarified publication rules for multilevel names. o Clarified publication rules for multilevel names.
skipping to change at page 21, line 5 skipping to change at page 21, line 9
o Added "handling" tag to express alleged sending domain's o Added "handling" tag to express alleged sending domain's
preference about handling of Suspicious messages. preference about handling of Suspicious messages.
o Clarified handling of SERVFAIL error in SSP check. o Clarified handling of SERVFAIL error in SSP check.
o Replaced "entity" with "domain", since with the removal of user- o Replaced "entity" with "domain", since with the removal of user-
granularity SSP, the only entities having sender signing policies granularity SSP, the only entities having sender signing policies
are domains. are domains.
D.8. Changes since -allman-ssp-02 D.9. Changes since -allman-ssp-02
o Removed user-granularity SSP and u= tag. o Removed user-granularity SSP and u= tag.
o Replaced DKIMP resource record with a TXT record. o Replaced DKIMP resource record with a TXT record.
o Changed name of the primary tag from "p" to "dkim". o Changed name of the primary tag from "p" to "dkim".
o Replaced lookup algorithm with one which traverses upward at most o Replaced lookup algorithm with one which traverses upward at most
one level. one level.
o Added description of records to be published, and effect of o Added description of records to be published, and effect of
wildcard records within the domain, on SSP. wildcard records within the domain, on SSP.
D.9. Changes since -allman-ssp-01 D.10. Changes since -allman-ssp-01
o Changed term "Sender Signing Policy" to "Sender Signing o Changed term "Sender Signing Policy" to "Sender Signing
Practices". Practices".
o Changed query methodology to use a separate DNS resource record o Changed query methodology to use a separate DNS resource record
type, DKIMP. type, DKIMP.
o Changed tag values from SPF-like symbols to words. o Changed tag values from SPF-like symbols to words.
o User level policies now default to that of the domain if not o User level policies now default to that of the domain if not
specified. specified.
o Removed the "Compliance" section since we're still not clear on o Removed the "Compliance" section since we're still not clear on
what goes here. what goes here.
o Changed the "parent domain" policy to only search up one level o Changed the "parent domain" policy to only search up one level
(assumes that subdomains will publish SSP records if appropriate). (assumes that subdomains will publish SSP records if appropriate).
o Added detailed description of SSP check procedure. o Added detailed description of SSP check procedure.
D.10. Changes since -allman-ssp-00 D.11. Changes since -allman-ssp-00
From a "diff" perspective, the changes are extensive. Semantically, From a "diff" perspective, the changes are extensive. Semantically,
the changes are: the changes are:
o Added section on "Third-Party Signatures and Mailing Lists" o Added section on "Third-Party Signatures and Mailing Lists"
o Added "Compliance" (transferred from -base document). I'm not o Added "Compliance" (transferred from -base document). I'm not
clear on what needs to be done here. clear on what needs to be done here.
o Extensive restructuring. o Extensive restructuring.
 End of changes. 19 change blocks. 
37 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/