idnits 2.17.1 draft-ietf-dkim-ssp-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 11, 2009) is 5458 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'FWS' is mentioned on line 1045, but not defined ** Obsolete normative reference: RFC 4871 (Obsoleted by RFC 6376) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5451 (Obsoleted by RFC 7001) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Allman 3 Internet-Draft Sendmail, Inc. 4 Intended status: Standards Track J. Fenton 5 Expires: November 12, 2009 Cisco Systems, Inc. 6 M. Delany 7 Yahoo! Inc. 8 J. Levine 9 Taughannock Networks 10 May 11, 2009 12 DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) 13 draft-ietf-dkim-ssp-10 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 12, 2009. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 DomainKeys Identified Mail (DKIM) defines a domain-level 52 authentication framework for email to permit verification of the 53 source and contents of messages. This document specifies an adjunct 54 mechanism to aid in assessing messages that do not contain a DKIM 55 signature for the domain used in the author's address. It defines a 56 record that can advertise whether a domain signs its outgoing mail, 57 and how other hosts can access that record. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Language and Terminology . . . . . . . . . . . . . . . . . . . 4 63 2.1. Terms Imported from DKIM Signatures Specification . . . . 4 64 2.2. Valid Signature . . . . . . . . . . . . . . . . . . . . . 5 65 2.3. Author Address . . . . . . . . . . . . . . . . . . . . . . 5 66 2.4. Author Domain . . . . . . . . . . . . . . . . . . . . . . 5 67 2.5. Alleged Author . . . . . . . . . . . . . . . . . . . . . . 5 68 2.6. Author Domain Signing Practices . . . . . . . . . . . . . 5 69 2.7. Author Domain Signature . . . . . . . . . . . . . . . . . 5 70 3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. ADSP Applicability . . . . . . . . . . . . . . . . . . . . 6 72 3.2. ADSP Usage . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.3. ADSP Results . . . . . . . . . . . . . . . . . . . . . . . 7 74 4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 7 75 4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 7 76 4.2. Publication of ADSP Records . . . . . . . . . . . . . . . 8 77 4.3. ADSP Lookup Procedure . . . . . . . . . . . . . . . . . . 9 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 5.1. ADSP Specification Tag Registry . . . . . . . . . . . . . 10 80 5.2. ADSP Outbound Signing Practices Registry . . . . . . . . . 10 81 5.3. Authentication-Results Method Registry Update . . . . . . 11 82 5.4. Authentication-Results Result Registry Update . . . . . . 11 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 6.1. ADSP Threat Model . . . . . . . . . . . . . . . . . . . . 13 85 6.2. DNS Considerations . . . . . . . . . . . . . . . . . . . . 14 86 6.3. DNS Wildcards . . . . . . . . . . . . . . . . . . . . . . 15 87 6.4. Inappropriate Application of Author Domain Signatures . . 15 88 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 7.1. References - Normative . . . . . . . . . . . . . . . . . . 15 90 7.2. References - Informative . . . . . . . . . . . . . . . . . 16 91 Appendix A. Lookup Examples . . . . . . . . . . . . . . . . . . . 16 92 A.1. Domain and ADSP exist . . . . . . . . . . . . . . . . . . 17 93 A.2. Domain exists, ADSP does not exist . . . . . . . . . . . . 17 94 A.3. Domain does not exist . . . . . . . . . . . . . . . . . . 17 95 Appendix B. Usage Examples . . . . . . . . . . . . . . . . . . . 17 96 B.1. Single Location Domains . . . . . . . . . . . . . . . . . 18 97 B.2. Bulk Mailing Domains . . . . . . . . . . . . . . . . . . . 18 98 B.3. Bulk Mailing Domains with Discardable Mail . . . . . . . . 19 99 B.4. Third Party Senders . . . . . . . . . . . . . . . . . . . 19 100 B.5. Domains with Independent Users and Liberal Use Policies . 19 101 B.6. Non-email Domains . . . . . . . . . . . . . . . . . . . . 19 102 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 19 103 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 20 104 D.1. Changes since -ietf-dkim-09 . . . . . . . . . . . . . . . 20 105 D.2. Changes since -ietf-dkim-08 . . . . . . . . . . . . . . . 20 106 D.3. Changes since -ietf-dkim-07 . . . . . . . . . . . . . . . 20 107 D.4. Changes since -ietf-dkim-06 . . . . . . . . . . . . . . . 20 108 D.5. Changes since -ietf-dkim-05 . . . . . . . . . . . . . . . 21 109 D.6. Changes since -ietf-dkim-04 . . . . . . . . . . . . . . . 21 110 D.7. Changes since -ietf-dkim-03 . . . . . . . . . . . . . . . 21 111 D.8. Changes since -ietf-dkim-02 . . . . . . . . . . . . . . . 22 112 D.9. Changes since -ietf-dkim-ssp-01 . . . . . . . . . . . . . 22 113 D.10. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 23 114 D.11. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 24 115 D.12. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 24 116 D.13. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 25 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 119 1. Introduction 121 DomainKeys Identified Mail (DKIM) defines a mechanism by which email 122 messages can be cryptographically signed, permitting a signing domain 123 to claim responsibility for the introduction of a message into the 124 mail stream. Message recipients can verify the signature by querying 125 the signer's domain directly to retrieve the appropriate public key, 126 and thereby confirm that the message was attested to by a party in 127 possession of the private key for the signing domain. 129 However, the legacy of the Internet is such that not all messages 130 will be signed, and the absence of a signature on a message is not an 131 a priori indication of forgery. In fact, during early phases of 132 deployment it is very likely that most messages will remain unsigned. 133 However, some domains might decide to sign all of their outgoing 134 mail, for example, to protect their brand names. It might be 135 desirable for such domains to be able to advertise that fact to other 136 hosts. This is the topic of Author Domain Signing Practices (ADSP). 138 Hosts implementing this specification can inquire what Author Domain 139 Signing Practices a domain advertises. This inquiry is called an 140 Author Domain Signing Practices check. 142 The basic requirements for ADSP are given in [RFC5016]. This 143 document refers extensively to [RFC4871] and assumes the reader is 144 familiar with it. 146 Requirements Notation: The key words "MUST", "MUST NOT", 147 "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 148 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 149 interpreted as described in [RFC2119] 151 2. Language and Terminology 153 2.1. Terms Imported from DKIM Signatures Specification 155 Some terminology used herein is derived directly from [RFC4871]. In 156 several cases, references in that document to Sender have been 157 changed to Author here, to emphasize the relationship to the Author 158 address(es) in the From: header field described in [RFC5322]. 159 Briefly, 161 o A "Signer" is the agent that signs a message, as defined in 162 section 2.1 of [RFC4871]. 164 o A "Local-part" is the part of an address preceding the @ 165 character, as defined in [RFC5322] and used in [RFC4871]. 167 2.2. Valid Signature 169 A "Valid Signature" is any signature on a message which correctly 170 verifies using the procedure described in section 6.1 of [RFC4871]. 172 2.3. Author Address 174 An "Author Address" is an email address in the From header field of a 175 message [RFC5322]. If the From header field contains multiple 176 addresses, the message has multiple Author Addresses. 178 2.4. Author Domain 180 An "Author Domain" is everything to the right of the "@" in an Author 181 Address (excluding the "@" itself). 183 2.5. Alleged Author 185 An "Alleged Author" is an Author Address of a message; it is 186 "alleged" because it has not yet been checked. 188 2.6. Author Domain Signing Practices 190 "Author Domain Signing Practices" (or just "practices") consist of a 191 machine-readable record published by the domain of an Alleged Author 192 which includes statements about the domain's practices with respect 193 to mail it sends with its domain in the From: line. 195 2.7. Author Domain Signature 197 An "Author Domain Signature" is a Valid Signature in which the domain 198 name of the DKIM signing entity, the d= tag in the DKIM-Signature 199 header field, is the same as the domain name in the Author Address. 200 Following [RFC5321], domain name comparisons are case insensitive. 202 For example, if the From: line address is bob@domain.example, and the 203 message has a Valid Signature, with the DKIM-Signature header field 204 containing "d=domain.example", then the message has an Author Domain 205 Signature. 207 3. Operation Overview 209 Domain owners publish ADSP information via a query mechanism such as 210 the Domain Name System; specific details are given in Section 4.1. 212 Hosts can look up the ADSP information of the domain(s) specified by 213 the Author Address(es) as described in Section 4.3. If a message has 214 multiple Author Addresses the ADSP lookups SHOULD be performed 215 independently on each address. This document does not address the 216 process a host might use to combine the lookup results. 218 3.1. ADSP Applicability 220 ADSP as defined in this document is bound to DNS. For this reason, 221 ADSP is applicable only to Author Domains with appropriate DNS 222 records (see Note below). The handling of other Author Domains is 223 outside the scope of this document. However, attackers may use such 224 domain names in a deliberate attempt to sidestep an organization's 225 ADSP policy statements. It is up to the ADSP checker implementation 226 to return an appropriate error result for Author Domains outside the 227 scope of ADSP. 229 ADSP applies to specific domains, not domain subtrees. If, for 230 example, an Author Address were user@domain.example, the Author 231 Domain would be domain.example, and the applicable ADSP record would 232 be at _adsp._domainkey.domain.example. An Author Address in a 233 subdomain such as user@sub.domain.example would have a different ADSP 234 record at _adsp._domainkey.sub.domain.example. ADSP makes no 235 connection between a domain and its parent or child domains. 237 Note: If an organization wants to publish Author Domain Signing 238 Practices for all the subdomains it uses, such as host names of 239 servers within the domain, it does so by creating ADSP records for 240 every _adsp._domainkey..domain.example. Wildcards cannot be 241 used (see Section 6.3.); however, suitable DNS management tools 242 could automate creation of the ADSP records. 244 Note: The results from DNS queries that are intended to validate a 245 domain name unavoidably approximate the set of Author Domains that 246 can appear in legitimate email. For example, a DNS A record could 247 belong to a device that does not even have an email 248 implementation. It is up to the checker to decide what degree of 249 approximation is acceptable. 251 3.2. ADSP Usage 253 Depending on the Author Domain(s) and the signatures in a message, a 254 recipient gets varying amounts of useful information from each ADSP 255 lookup. 257 o If a message has no Valid Signature, the ADSP result is directly 258 relevant to the message. 260 o If a message has an Author Domain Signature, ADSP provides no 261 benefit relative to that domain since the message is already known 262 to be compliant with any possible ADSP for that domain. 264 o If a message has a Valid Signature other than an Author Domain 265 Signature, the receiver can use both the Signature and the ADSP 266 result in its evaluation of the message. 268 3.3. ADSP Results 270 An ADSP lookup for an Author Address produces one of four possible 271 results: 273 o Messages from this domain might or might not have an author domain 274 signature. This is the default if the domain exists in the DNS 275 but no ADSP record is found. 277 o All messages from this domain are signed with an Author Domain 278 Signature. 280 o All messages from this domain are signed with an Author Domain 281 Signature and discardable, i.e., if a message arrives without a 282 valid Author Domain Signature, the domain encourages the 283 recipient(s) to discard it. 285 o This domain is out of scope, i.e., the domain does not exist in 286 the DNS. 288 An ADSP lookup could terminate without producing any result if a DNS 289 lookup results in a temporary failure. 291 4. Detailed Description 293 4.1. DNS Representation 295 ADSP records are published using the DNS TXT resource record type. 297 The RDATA for ADSP resource records is textual in format, with 298 specific syntax and semantics relating to their role in describing 299 ADSP. The "Tag=Value List" syntax described in section 3.2 of 300 [RFC4871] is used, modified to use WSP rather than FWS. Records not 301 in compliance with that syntax or the syntax of individual tags 302 described in Section 4.3 MUST be ignored (considered equivalent to a 303 NODATA result) for purposes of ADSP, although they MAY cause the 304 logging of warning messages via an appropriate system logging 305 mechanism. If the RDATA contains multiple character strings, the 306 strings are logically concatenated with no delimiters between the 307 strings. 309 Note: ADSP changes the "Tag=Value List" syntax from [RFC4871] to 310 use WSP rather than FWS in its DNS records. 312 Note: Domains MUST NOT publish ADSP records with wildcard names. 313 Wildcards within a domain publishing ADSP records pose a 314 particular problem, as discussed in more detail in Section 6.3. 316 4.2. Publication of ADSP Records 318 ADSP is intended to apply to all mail sent using the domain name 319 string of an Alleged Author. 321 4.2.1. Record Syntax 323 ADSP records use the "tag=value" syntax described in section 3.2 of 324 [RFC4871], modified to use WSP rather than FWS. Every ADSP record 325 MUST start with an outbound signing practices tag, so the first four 326 characters of the record are lower case "dkim", followed by optional 327 whitespace and "=". 329 Tags used in ADSP records are described below. Unrecognized tags 330 MUST be ignored. In the ABNF below, the WSP token, and the ALPHA and 331 DIGIT tokens are imported from [RFC5234]. 333 dkim= Outbound signing practices for the domain (plain-text; 334 REQUIRED). Possible values are as follows: 336 unknown The domain might sign some or all email. 338 all All mail from the domain is signed with an Author Domain 339 Signature. 341 discardable All mail from the domain is signed with an Author 342 Domain Signature. Furthermore, if a message arrives without a 343 valid Author Domain Signature due to modification in transit, 344 submission via a path without access to a signing key, or any 345 other reason, the domain encourages the recipient(s) to discard 346 it. 348 Any other values are treated as "unknown". 350 ABNF: 351 adsp-dkim-tag = %x64.6b.69.6d *WSP "=" *WSP 352 ("unknown" / "all" / "discardable") 354 4.3. ADSP Lookup Procedure 356 Hosts doing an ADSP lookup MUST produce a result that is semantically 357 equivalent to applying the following steps in the order listed below. 358 In practice, these steps can be performed in parallel in order to 359 improve performance. However, implementations SHOULD avoid doing 360 unnecessary DNS lookups. 362 For the purposes of this section a "valid ADSP record" is one that is 363 both syntactically and semantically correct; in particular, it 364 matches the ABNF for a "tag-list" and starts with a valid "dkim" tag. 366 Check Domain Scope: An ADSP checker implementation MUST determine 367 whether a given Author Domain is within scope for ADSP. Given the 368 background in Section 3.1 the checker MUST decide which degree of 369 approximation is acceptable. The checker MUST return an 370 appropriate error result for Author Domains that are outside the 371 scope of ADSP. 373 The host MUST perform a DNS query for a record corresponding to 374 the Author Domain (with no prefix). The type of the query can be 375 of any type, since this step is only to determine if the domain 376 itself exists in DNS. This query MAY be done in parallel with the 377 query to fetch the named ADSP Record. If the result of this query 378 is that the Author domain does not exist in the DNS (often called 379 an NXDOMAIN error, rcode=3 in [RFC1035]), the algorithm MUST 380 terminate with an error indicating that the domain is out of 381 scope. Note that a result with rcode=0 but no records (often 382 called NODATA) is not the same as NXDOMAIN. 384 NON-NORMATIVE DISCUSSION: Any resource record type could be 385 used for this query since the existence of a resource record of 386 any type will prevent an NXDOMAIN error. MX is a reasonable 387 choice for this purpose because this record type is thought to 388 be the most common for domains used in e-mail, and will 389 therefore produce a result which can be more readily cached 390 than a negative result. 392 If the domain does exist, the checker MAY make more extensive 393 checks to verify the existence of the domain, such as the ones 394 described in Section 5 of [RFC5321]. If those checks indicate 395 that the Author domain does not exist for mail, e.g., the domain 396 has no MX, A, or AAAA record, the checker SHOULD terminate with an 397 error indicating that the domain is out of scope. 399 Fetch Named ADSP Record: The host MUST query DNS for a TXT record 400 corresponding to the Author Domain prefixed by "_adsp._domainkey." 401 (note the trailing dot). 403 If the result of this query is a NOERROR response (rcode=0 in 404 [RFC1035]) with an answer which is a single record that is a valid 405 ADSP record, use that record, and the algorithm terminates. 407 If the result of the query is NXDOMAIN or NOERROR with zero 408 records, there is no ADSP record. If the result of the query 409 contains more than one record, or a record that is not a valid 410 ADSP record, the ADSP result is undefined. 412 If a query results in a "SERVFAIL" error response (rcode=2 in 413 [RFC1035]), the algorithm terminates without returning a result; 414 possible actions include queuing the message or returning an SMTP 415 error indicating a temporary failure. 417 See Appendix A for examples of ADSP Lookup. 419 5. IANA Considerations 421 ADSP adds the following namespaces to the IANA registry. In all 422 cases, new values are assigned only for values that have been 423 documented in a published RFC after IETF Review as specified in 424 [RFC5226]. 426 5.1. ADSP Specification Tag Registry 428 An ADSP record provides for a list of specification tags. IANA has 429 established the ADSP Specification Tag Registry for specification 430 tags that can be used in ADSP fields. 432 The initial entry in the registry is: 433 +------+-----------------+ 434 | TYPE | REFERENCE | 435 +------+-----------------+ 436 | dkim | (this document) | 437 +------+-----------------+ 438 ADSP Specification Tag Registry Initial Values 440 5.2. ADSP Outbound Signing Practices Registry 442 The "dkim=" tag spec, defined in Section 4.2.1, provides for a value 443 specifying Outbound Signing Practices. IANA has established the ADSP 444 Outbound Signing Practices Registry for Outbound Signing Practices. 446 The initial entries in the registry comprise: 447 +-------------+-----------------+ 448 | TYPE | REFERENCE | 449 +-------------+-----------------+ 450 | unknown | (this document) | 451 | all | (this document) | 452 | discardable | (this document) | 453 +-------------+-----------------+ 454 ADSP Outbound Signing Practices Registry Initial Values 456 5.3. Authentication-Results Method Registry Update 458 IANA is requested to add the following to the Email Authentication 459 Method Name Registry: 461 Method: dkim-adsp 463 Defined In: this memo 465 ptype: header 467 property: from 469 value: Contents of the [RFC5322] From: header field, with comments 470 removed 472 5.4. Authentication-Results Result Registry Update 474 IANA is requested to add or update the following in the Email 475 Authentication Result Name Registry: 477 Code: none 479 Existing/New Code: existing 481 Defined In: [RFC5451] 483 Auth Method: dkim-adsp (added) 485 Meaning: No DKIM author domain signing practises (ADSP) record was 486 published. 488 Code: pass 490 Existing/New Code: existing 491 Defined In: [RFC5451] 493 Auth Method: dkim-adsp (added) 495 Meaning: This message had an Author Domain Domain Signature that was 496 validated. (An ADSP check is not strictly required to be 497 performed for this result, since a valid Author Domain Signature 498 satisfies all possible ADSP policies.) 500 Code: unknown 502 Existing/New Code: new 504 Defined In: this memo 506 Auth Method: dkim-adsp 508 Meaning: No valid Author Domain Signature was found on the message 509 and the published ADSP was "unknown". 511 Code: fail 513 Existing/New Code: existing 515 Defined In: [RFC5451] 517 Auth Method: dkim-adsp (added) 519 Meaning: No valid Author Domain Signature was found on the message 520 and the published ADSP was "all". 522 Code: discard 524 Existing/New Code: new 526 Defined In: this memo 528 Auth Method: dkim-adsp 530 Meaning: No valid Author Domain Signature was found on the message 531 and the published ADSP was "discardable". 533 Code: nxdomain 535 Existing/New Code: new 536 Defined In: this memo 538 Auth Method: dkim-adsp 540 Meaning: Evaluating the ADSP for the Author's DNS domain indicated 541 that the Author's DNS domain does not exist. 543 Code: temperror 545 Existing/New Code: existing 547 Defined In: [RFC5451] 549 Auth Method: dkim-adsp (added) 551 Meaning: An ADSP record could not be retrieved due to some error 552 that is likely transient in nature, such as a temporary DNS error. 553 A later attempt may produce a final result. 555 Code: permerror 557 Existing/New Code: existing 559 Defined In: [RFC5451] 561 Auth Method: dkim-adsp (added) 563 Meaning: An ADSP record could not be retrieved due to some error 564 that is likely not transient in nature, such as a permanent DNS 565 error. A later attempt is unlikely to produce a final result. 567 6. Security Considerations 569 Security considerations in the ADSP are mostly related to attempts on 570 the part of malicious senders to represent themselves as authors for 571 whom they are not authorized to send mail, often in an attempt to 572 defraud either the recipient or an Alleged Author. 574 Additional security considerations regarding Author Domain Signing 575 Practices are found in the DKIM threat analysis [RFC4686]. 577 6.1. ADSP Threat Model 579 Email recipients often have a core set of content authors that they 580 already trust. Common examples include financial institutions with 581 which they have an existing relationship and Internet web transaction 582 sites with which they conduct business. 584 Email abuse often seeks to exploit a legitimate email author's name- 585 recognition among recipients, by using the author's domain name in 586 the From: header field. Especially since many popular MUAs do not 587 display the author's email address, there is no empirical evidence of 588 the extent that this particular unauthorized use of a domain name 589 contributes to recipient deception or that eliminating it will have 590 significant effect. 592 However, closing this exploit could facilitate some types of 593 optimized processing by receive-side message filtering engines, since 594 it could permit them to maintain higher-confidence assertions about 595 From: header field uses of a domain, when the occurrence is 596 authorized. 598 Unauthorized uses of domain names occur elsewhere in messages, as do 599 unauthorized uses of organizations' names. These attacks are outside 600 the scope of this specification. 602 ADSP does not provide any benefit--nor, indeed, have any effect at 603 all--unless an external system acts upon the verdict, either by 604 treating the message differently during the delivery process or by 605 showing some indicator to the end recipient. Such a system is out of 606 scope for this specification. 608 ADSP checkers may perform multiple DNS lookups per Alleged Author 609 Domain. Since these lookups are driven by domain names in email 610 message headers of possibly fraudulent email, legitimate ADSP 611 checkers can become participants in traffic multiplication attacks on 612 domains that appear in fraudulent email. 614 6.2. DNS Considerations 616 An attacker might attack the DNS infrastructure in an attempt to 617 impersonate ADSP records to influence a receiver's decision on how it 618 will handle mail. However, such an attacker is more likely to attack 619 at a higher level, e.g., redirecting A or MX record lookups in order 620 to capture traffic that was legitimately intended for the target 621 domain. These DNS security issues are addressed by DNSSEC [RFC4033]. 623 Because ADSP operates within the framework of the legacy e-mail 624 system, the default result in the absence of an ADSP record is that 625 the domain does not sign all of its messages. It is therefore 626 important that the ADSP clients distinguish a DNS failure such as 627 "SERVFAIL" from other DNS errors so that appropriate actions can be 628 taken. 630 6.3. DNS Wildcards 632 DNS wildcards (described in [RFC4592]) that exist in the DNS 633 hierarchy at or above the domain being checked interfere with the 634 ability to verify the scope of the ADSP check described in 635 Section 4.3. For example, a wildcard record for *.domain.example 636 makes all subdomains such as foo.domain.example exist in the DNS. 637 Domains that intend to make active use of ADSP by publishing a 638 practice other than Unknown are advised to avoid the use of wildcards 639 in their hierarchy. 641 If a domain contains wildcards, then any name that matches the 642 wildcard can appear to be a valid mail domain eligible for ADSP. But 643 the "_adsp._domainkey." prefix on ADSP records does not allow 644 publication of wildcard records that cover ADSP records without also 645 covering non-ADSP records, nor publication of wildcard records that 646 cover non-ADSP records without also covering ADSP records. A domain 647 that uses ADSP practices other than unknown SHOULD NOT publish 648 wildcard records. 650 6.4. Inappropriate Application of Author Domain Signatures 652 In one model of DKIM usage, a domain signs messages that are in 653 transit through their system. Since any signature whose domain 654 matches the Author Domain is by definition an Author Domain 655 Signature, it would be unwise to sign mail whose Author Domain is the 656 signer's domain if the mail is not known to meet the domain's 657 standards for an Author Domain Signature. 659 One such use case is where a domain might apply such a signature is 660 following application of an Authentication-Results header field as 661 described in Section 7.1 of [RFC5451]. This problem can be easily 662 avoided either by not applying a signature that might be confused 663 with an Author Domain Signature or by applying a signature from some 664 other domain, such as a subdomain of the Author Domain. 666 7. References 668 7.1. References - Normative 670 [RFC1035] Mockapetris, P., "Domain names - implementation and 671 specification", STD 13, RFC 1035, November 1987. 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, March 1997. 676 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 678 Rose, "DNS Security Introduction and Requirements", 679 RFC 4033, March 2005. 681 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 682 System", RFC 4592, July 2006. 684 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 685 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 686 Signatures", RFC 4871, May 2007. 688 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 689 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 690 May 2008. 692 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 693 Specifications: ABNF", STD 68, RFC 5234, January 2008. 695 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 696 October 2008. 698 [RFC5451] Kucherawy, M., "Message Header Field for Indicating 699 Message Authentication Status", RFC 5451, April 2009. 701 7.2. References - Informative 703 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys 704 Identified Mail (DKIM)", RFC 4686, September 2006. 706 [RFC5016] Thomas, M., "Requirements for a DomainKeys Identified Mail 707 (DKIM) Signing Practices Protocol", RFC 5016, 708 October 2007. 710 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 711 October 2008. 713 Appendix A. Lookup Examples 715 Assume the example domain publishes these DNS records: (In these 716 examples, the numbers in parentheses are comments to help identify 717 the records, not part of the records themselves.) 719 aaa.example A 192.0.2.1 (1) 720 _adsp._domainkey.aaa.example TXT "dkim=all" (2) 722 bbb.example MX 10 mail.bbb.example (3) 723 mail.bbb.example A 192.0.2.2 (4) 725 A.1. Domain and ADSP exist 727 A mail message contains this From: header line: 729 From: bob@aaa.example (Bob the Author) 731 The ADSP Lookup first identifies the Author Address bob@aaa.example 732 and the Author Domain aaa.example. It does an MX DNS query for 733 aaa.example, and gets back a NOERROR result with no DNS records. 734 (There's no MX record, but since record (1) exists, the name exists 735 in the DNS.) Since that query didn't return an error, the Lookup 736 proceeds to a TXT DNS query for _adsp._domainkey.aaa.example, which 737 returns record (2). Since this is a valid DKIM record, the result is 738 that all messages from this domain are signed. 740 A.2. Domain exists, ADSP does not exist 742 A mail message contains this From: header line: 744 From: alice@bbb.example (Old-fashioned Alice) 746 The ADSP Lookup first identifies the Author Address alice@bbb.example 747 and the Author Domain bbb.example. It does an MX DNS query for 748 bbb.example, and gets back record (3). Since that query didn't 749 return an error, it then proceeds to a TXT DNS query for 750 _adsp._domainkey.bbb.example, which returns NXDOMAIN. Since the 751 domain exists but there is no ADSP record, ADSP returns the default 752 unknown result: messages may or may not have an author domain 753 signature. 755 A.3. Domain does not exist 757 A mail message contains this From: header line: 759 From: frank@ccc.example (Unreliable Frank) 761 The ADSP Lookup first identifies the Author Address frank@ccc.example 762 and the Author Domain ccc.example. It does an MX DNS query for 763 ccc.example, and gets back an NXDOMAIN result since there are no 764 records at all for ccc.example. The lookup terminates with the 765 result that the domain does not exist in the DNS and so is out of 766 scope. 768 Appendix B. Usage Examples 770 These examples are intended to illustrate typical uses of ADSP. They 771 are not intended to be exhaustive, nor to apply to every domain's or 772 mail system's individual situation. 774 Domain managers are advised to consider the ways that mail processing 775 can modify messages in ways that will invalidate an existing DKIM 776 signature, such as mailing lists, courtesy forwarders, and other 777 paths that could add or modify headers, or modify the message body. 778 In that case, if the modifications invalidate the DKIM signature, 779 recipient hosts will consider the mail not to have an Author Domain 780 Signature, even though the signature was present when the mail was 781 originally sent. 783 B.1. Single Location Domains 785 A common mail system configuration handles all of a domain's users' 786 incoming and outgoing mail through a single MTA or group of MTAs. In 787 that case, the MTA(s) can be configured to sign outgoing mail with an 788 Author Domain Signature. 790 In this situation it might be appropriate to publish an ADSP record 791 for the domain containing "all", depending on whether the users also 792 send mail through other paths that do not apply an Author Domain 793 Signature. Such paths could include MTAs at hotels or hotspot 794 networks used by travelling users, web sites that provide "mail an 795 article" features, user messages sent through mailing lists, or third 796 party mail clients that support multiple user identities. 798 B.2. Bulk Mailing Domains 800 Another common configuration uses a domain solely for bulk or 801 broadcast mail, with no individual human users, again typically 802 sending all the mail through a single MTA or group of MTAs that can 803 apply an Author Domain Signature. In this case, the domain's 804 management can be confident that all of its outgoing mail will be 805 sent through the signing MTA. Lacking individual users, the domain 806 is unlikely to participate in mailing lists, but could still send 807 mail through other paths that might invalidate signatures. 809 Domain owners often use specialist mailing providers to send their 810 bulk mail. In that case, the mailing provider needs access to a 811 suitable signing key in order to apply an Author Domain Signature. 812 One possible route would be for the domain owner to generate the key 813 and give it to the mailing provider. Another would be for the domain 814 to delegate a subdomain to the mailing provider, for example, 815 bigbank.example might delegate email.bigbank.example to such a 816 provider. In that case, the provider can generate the keys and DKIM 817 DNS records itself and use the subdomain in the Author address in the 818 mail. 820 Regardless of the DNS and key management strategy chosen, whoever 821 maintains the DKIM records for the domain could also install an ADSP 822 record containing "all". 824 B.3. Bulk Mailing Domains with Discardable Mail 826 In some cases, a domain might sign all of its outgoing mail with an 827 Author Domain Signature, but prefer that recipient systems discard 828 mail without a valid Author Domain Signature to avoid confusion from 829 mail sent from sources that do not apply an Author Domain Signature. 830 (In the case of domains with tightly controlled outgoing mail, this 831 latter kind of mail is sometimes loosely called "forgeries".) In 832 that case, it might be appropriate to publish an ADSP record 833 containing "discardable". Note that a domain SHOULD NOT publish a 834 "discardable" record if it wishes to maximize the likelihood that 835 mail from the domain is delivered, since it could cause some fraction 836 of the mail the domain sends to be discarded. 838 B.4. Third Party Senders 840 Another common use case is for a third party to enter into an 841 agreement whereby that third party will send bulk or other mail on 842 behalf of a designated author or author domain, using that domain in 843 the RFC5322 From: or other headers. Due to the many and varied 844 complexities of such agreements, third party signing is not addressed 845 in this specification. 847 B.5. Domains with Independent Users and Liberal Use Policies 849 When a domain has independent users and its usage policy does not 850 explicitly restrict them to sending mail only from designated mail 851 servers (e.g. many ISP domains and even some corporate domains), then 852 it is only appropriate to publish an ADSP record containing 853 "unknown". Publishing either "all" or "discardable" will likely 854 result in significant breakage because independent users are likely 855 to send mail from the external paths enumerated in Appendix B.1. 857 B.6. Non-email Domains 859 If a domain sends no mail at all, it can safely publish a 860 "discardable" ADSP record, since any mail with an author address in 861 the domain is a forgery. 863 Appendix C. Acknowledgements 865 This document greatly benefited from comments by Steve Atkins, Jon 866 Callas, Dave Crocker, Pasi Eronen, JD Falk, Arvel Hathcock, Ellen 867 Siegel, Michael Thomas, and Wietse Venema. 869 Appendix D. Change Log 871 *NOTE TO RFC EDITOR: This section may be removed upon publication of 872 this document as an RFC.* 874 D.1. Changes since -ietf-dkim-09 876 o Change author signature to use d=. 878 o Change all "author signature" to "author domain signature". 880 o Add authentication results for IANA per Murray K. 882 o Minor editorial clarifications. 884 D.2. Changes since -ietf-dkim-08 886 o Simplify and clarify interpretation of d= and i=. 888 o Add note pointing out that i= usage conflicts with normal usage, 889 and suggest workaround. 891 o Add note pointing out that you can mechanically add ADSP records 892 for all the subdomains you use. 894 o in Section 3.2 fix text to say that only an Author Signature 895 counts. 897 D.3. Changes since -ietf-dkim-07 899 Clarify that ADSP records use WSP rather than FWS in 4.1 and 4.2.1. 901 D.4. Changes since -ietf-dkim-06 903 Minor editorial changes suggested by AD: 905 o expand DKIM in title 907 o clarify that there's no subdomain matching in Section 3.1 909 o ADSP lookup can terminate without a result if the DNS lookup fails 911 o random dkim= values are treated as unknown 912 o in 4.2 note WSP not FWS 914 o in 4.3 note that NODATA is not NXDOMAIN 916 o add new Appendix A with lookup examples 918 Also address Tony's nits in 919 http://mipassoc.org/pipermail/ietf-dkim/2008q3/010720.html. Make the 920 examples consistently use the .example domain. 922 D.5. Changes since -ietf-dkim-05 924 Minor editorial nits: define NOERROR, SERVFAIL, NXDOMAIN as rfc1035 925 rcodes, change some punctuation, IANA section change IETF Consensus 926 to the new IETF Review. 928 D.6. Changes since -ietf-dkim-04 930 o Require dkim at the front of each record. 932 o Disparage wildcard records. 934 o Changed ABNF use of whitespace from FWS back to WSP, dkim-base is 935 wrong. 937 o RFC 2434 -> 5226, make ref to 4686 informational since it's not 938 standards track. 940 o Improve examples with material from Ellen. 942 D.7. Changes since -ietf-dkim-03 944 o Name change for title and filename, to be ADSP 946 o String changes throughout, to author Domain signing practices and 947 to aDsp. 949 o Added some keywords. 951 o Clarified comparison of local part and domain in Author Address. 953 o Streamlined the Abstract. 955 o Revised text of last bullet in Results list. 957 o Removed definitions not used in the document. 959 o Removed all specification details pertaining to sub-domains. 961 o Moved Lookup Procedure up one document level. 963 o Revised domain validity specification. Part in ADSP Usage in 964 Operations section, and part as it as first step in Lookup. 966 o Fixed xml for figures, including labeling ABNF with new xml2rfc 967 construct. 969 o Revised wildcard text. 971 o Removed 't' tag. 973 o Removed ADSP Flags Registry section. 975 o Changed ABNF use of whitespace from WSP back to FWS, for 976 consistency with dkim-base. 978 D.8. Changes since -ietf-dkim-02 980 o Merge in more text from ADSP draft. 982 o Phrase actions as host's rather than checker. 984 o Explanatory description of i= matching. 986 o Lookup procedure consistently refers to one ADSP record per 987 lookup. 989 o Update security section w/ language from W. Venema 991 o Simplify imports of terms from other RFCs, add Local-part, 4234 -> 992 5234. 994 o Add usage example appendix. 996 o Add IANA considerations. 998 o Update authors list 1000 D.9. Changes since -ietf-dkim-ssp-01 1002 o Reworded introduction for clarity. 1004 o Various definition clarifications. 1006 o Changed names of practices to unknown, all, and discardable. 1008 o Removed normative language mandating use of SSP in particular 1009 situations (issue 1538). 1011 o Clarified possible confusion over handling of syntax errors. 1013 o Removed normative language from Introduction (issue 1538). 1015 o Changed "Originator" to "Author" throughout (issue 1529). 1017 o Removed all references to Third-Party Signatures (issues 1512, 1018 1521). 1020 o Removed all mention of "Suspicious" (issues 1528, 1530). 1022 o Removed "t=y" (testing) flag (issue 1540). 1024 o Removed "handling" tag (issue 1513). 1026 o Broke up the "Sender Signing Practices Check Procedure" into two 1027 algorithms: fetching the SSP record and interpretation thereof 1028 (issues 1531, 1535; partially addresses issue 1520). 1029 Interpretation is now the responsibility of the Evaluator. 1031 o Document restructuring for better flow and remove redundancies 1032 (some may address issue 1523, but I'm not sure I understand that 1033 issue completely; also issues 1532, 1537). 1035 o Removed all mention of how this interacts with users, even though 1036 it makes parts of the document harder to understand (issue 1526). 1038 o Introduced the concepts of "SSP Checker" and "Evaluator". 1040 o Multiple author case now handled my separate invocations of SSP 1041 checker by Evaluator (issue 1525). 1043 o Removed check to avoid querying top-level domains. 1045 o Changed ABNF use of whitespace from [FWS] to *WSP (partially 1046 addresses issue 1543). 1048 D.10. Changes since -ietf-dkim-ssp-00 1050 o Clarified Operation Overview and eliminated use of Legitimate as 1051 the counterpart of Suspicious since the words have different 1052 meanings. 1054 o Improved discussion (courtesy of Arvel Hathcock) of the use of TXT 1055 records in DNS vs. a new RR type. 1057 o Clarified publication rules for multilevel names. 1059 o Better description of overall record syntax, in particular that 1060 records with unknown tags are considered syntactically correct. 1062 o Clarified Sender Signing Practices Check Procedure, primarily by 1063 use of new term Author Domain. 1065 o Eliminated section "Third-Party Signatures and Mailing Lists" that 1066 is better included in the DKIM overview document. 1068 o Added "handling" tag to express alleged sending domain's 1069 preference about handling of Suspicious messages. 1071 o Clarified handling of SERVFAIL error in SSP check. 1073 o Replaced "entity" with "domain", since with the removal of user- 1074 granularity SSP, the only entities having sender signing policies 1075 are domains. 1077 D.11. Changes since -allman-ssp-02 1079 o Removed user-granularity SSP and u= tag. 1081 o Replaced DKIMP resource record with a TXT record. 1083 o Changed name of the primary tag from "p" to "dkim". 1085 o Replaced lookup algorithm with one which traverses upward at most 1086 one level. 1088 o Added description of records to be published, and effect of 1089 wildcard records within the domain, on SSP. 1091 D.12. Changes since -allman-ssp-01 1093 o Changed term "Sender Signing Policy" to "Sender Signing 1094 Practices". 1096 o Changed query methodology to use a separate DNS resource record 1097 type, DKIMP. 1099 o Changed tag values from SPF-like symbols to words. 1101 o User level policies now default to that of the domain if not 1102 specified. 1104 o Removed the "Compliance" section since we're still not clear on 1105 what goes here. 1107 o Changed the "parent domain" policy to only search up one level 1108 (assumes that subdomains will publish SSP records if appropriate). 1110 o Added detailed description of SSP check procedure. 1112 D.13. Changes since -allman-ssp-00 1114 From a "diff" perspective, the changes are extensive. Semantically, 1115 the changes are: 1117 o Added section on "Third-Party Signatures and Mailing Lists" 1119 o Added "Compliance" (transferred from -base document). I'm not 1120 clear on what needs to be done here. 1122 o Extensive restructuring. 1124 Authors' Addresses 1126 Eric Allman 1127 Sendmail, Inc. 1128 6475 Christie Ave, Suite 350 1129 Emeryville, CA 94608 1131 Phone: +1 510 594 5501 1132 Email: eric+dkim@sendmail.org 1134 Jim Fenton 1135 Cisco Systems, Inc. 1136 MS SJ-9/2 1137 170 W. Tasman Drive 1138 San Jose, CA 95134-1706 1140 Phone: +1 408 526 5914 1141 Email: fenton@cisco.com 1142 Mark Delany 1143 Yahoo! Inc. 1144 701 First Avenue 1145 Sunnyvale, CA 94089 1147 Phone: +1 408 349 6831 1148 Email: markd+dkim@yahoo-inc.com 1150 John Levine 1151 Taughannock Networks 1152 PO Box 727 1153 Trumansburg, NY 14886 1155 Phone: +1 831 480 2300 1156 Email: standards@taugh.com 1157 URI: http://www.taugh.com