idnits 2.17.1 draft-ietf-dkim-ssp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 771. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 782. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 789. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 795. 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 abstract seems to contain references ([RFC4871]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (September 17, 2007) is 6059 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) == Unused Reference: 'RFC1035' is defined on line 611, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4871 (Obsoleted by RFC 6376) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DKIM Working Group E. Allman 3 Internet-Draft Sendmail, Inc. 4 Intended status: Standards Track M. Delany 5 Expires: March 20, 2008 Yahoo! Inc. 6 J. Fenton 7 Cisco Systems, Inc. 8 September 17, 2007 10 DKIM Sender Signing Practices 11 draft-ietf-dkim-ssp-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of 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 March 20, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 DomainKeys Identified Mail (DKIM) defines a domain-level 45 authentication framework for email using public-key cryptography and 46 key server technology to permit verification of the source and 47 contents of messages by either Mail Transport Agents (MTAs) or Mail 48 User Agents (MUAs). The primary DKIM protocol is described in 50 [RFC4871]. 52 This document describes the records that senders may use to advertise 53 how they sign their outgoing mail, and how verifiers should access 54 and interpret those results. 56 Requirements Language 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in [RFC2119]. 62 (Unresolved Issues/To Be Done) 64 Need to consider handling of multiple responses to a DNS query for 65 the SSP record. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Language and Terminology . . . . . . . . . . . . . . . . . . . 5 71 2.1. Terms Imported from DKIM Signatures Specification . . . . 5 72 2.2. Valid Signature . . . . . . . . . . . . . . . . . . . . . 5 73 2.3. Originator Address . . . . . . . . . . . . . . . . . . . . 5 74 2.4. Originator Domain . . . . . . . . . . . . . . . . . . . . 6 75 2.5. Alleged Signer . . . . . . . . . . . . . . . . . . . . . . 6 76 2.6. Alleged Originator . . . . . . . . . . . . . . . . . . . . 6 77 2.7. Sender Signing Practices . . . . . . . . . . . . . . . . . 6 78 2.8. Originator Signature . . . . . . . . . . . . . . . . . . . 6 79 2.9. Suspicious . . . . . . . . . . . . . . . . . . . . . . . . 6 80 2.10. Third-Party Signature . . . . . . . . . . . . . . . . . . 7 81 2.11. Verifier Acceptable Third-Party Signature . . . . . . . . 7 82 3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 7 83 4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 8 84 4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 8 85 4.2. Publication of SSP Records . . . . . . . . . . . . . . . . 9 86 4.3. Record Syntax . . . . . . . . . . . . . . . . . . . . . . 10 87 4.4. Sender Signing Practices Check Procedure . . . . . . . . . 12 88 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 90 6.1. Fraudulent Sender Address . . . . . . . . . . . . . . . . 14 91 6.2. DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 14 92 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 94 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 95 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 96 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 15 97 B.1. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 15 98 B.2. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 16 99 B.3. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 16 100 B.4. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 16 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 102 Intellectual Property and Copyright Statements . . . . . . . . . . 18 104 1. Introduction 106 DomainKeys Identified Mail (DKIM) defines a mechanism by which email 107 messages can be cryptographically signed, permitting a signing domain 108 to claim responsibility for the introduction of a message into the 109 mail stream. Message recipients can verify the signature by querying 110 the signer's domain directly to retrieve the appropriate public key, 111 and thereby confirm that the message was attested to by a party in 112 possession of the private key for the signing domain. 114 However, the legacy of the Internet is such that not all messages 115 will be signed, and the absence of a signature on a message is not an 116 a priori indication of forgery. In fact, during early phases of 117 deployment it must be expected that most messages will remain 118 unsigned. However, some domains may choose to sign all of their 119 outgoing mail, for example, to protect their brand name. It is 120 highly desirable for such domains to be able to advertise that fact 121 to verifiers, and that messages claiming to be from them that do not 122 have a valid signature are likely to be forgeries. This is the topic 123 for sender signing practices. 125 In the absence of a valid DKIM signature on behalf of the "From" 126 address [RFC2822], message verifiers implementing this specification 127 MUST determine whether messages from that sender are expected to be 128 signed, and what signatures are acceptable. In particular, whether a 129 domain signs all outbound email must be made available to the 130 verifier. Without such a mechanism, the benefit of message signing 131 techniques such as DKIM is limited since unsigned messages will 132 always need to be considered to be potentially legitimate. This 133 determination is referred to as a Sender Signing Practices check. 135 Conceivably, such expressions might be imagined to be extended in the 136 future to include information about what hashing algorithms a domain 137 uses, what kind of messages might be sent (e.g., bulk vs. personal 138 vs. transactional), etc. Such concerns are out of scope of this 139 standard, because they can be expressed in the key record 140 ("Selector") with which the signature is verified. In contrast, this 141 specification focuses on information which is relevant in the absence 142 of a valid signature. Expressions of signing practice which require 143 outside auditing are similarly out of scope for this specification 144 because they fall under the purview of reputation and accreditation. 146 The detailed requirements for Sender Signing Practices are given in 147 [I-D.ietf-dkim-ssp-requirements], which the protocol described in 148 this document attempts to satisfy. This document refers extensively 149 to [RFC4871], which should be read as a prerequisite to this 150 document. 152 2. Language and Terminology 154 2.1. Terms Imported from DKIM Signatures Specification 156 Some terminology used herein is derived directly from [RFC4871]. 157 Briefly, 159 o A "Signer" is the agent that signs a message. In many cases it 160 will correspond closely with the original author of the message or 161 an agent working on the author's behalf. 163 o A "Verifier" is the agent that verifies a message by checking the 164 actual signature against the message itself and the public key 165 published by the Alleged Signer. The Verifier also looks up the 166 Sender Signing Practices published by the domain of the Originator 167 Address if the message is not correctly signed by the Alleged 168 Originator. 170 o A "Selector" specifies which of the keys published by a signing 171 domain should be queried. It is essentially a way of subdividing 172 the address space to allow a single sending domain to publish 173 multiple keys. 175 2.2. Valid Signature 177 A "Valid Signature" is any signature on a message which correctly 178 verifies using the procedure described in section 6.1 of [RFC4871]. 180 2.3. Originator Address 182 The "Originator Address" is the email address in the From header 183 field of a message [RFC2822], or if and only if the From header field 184 contains multiple addresses, the first address in the From header 185 field. 187 NON-NORMATIVE RATIONALE: The alternative option when there are 188 multiple addresses in the From header field is to use the value of 189 the Sender header field. This would be closer to the semantics 190 indicated in [RFC2822] than using the first address in the From 191 header field. However, the large number of deployed Mail User 192 Agents that do not display the Sender header field value argues 193 against that. Multiple addresses in the From header field are 194 rare in real life. 196 Even when there is only one address in the From header field, this 197 address is chosen as the reference address for SSP lookups because 198 it represents the author of the message and is more widely 199 displayed by Mail User Agents as a result. The Sender header 200 field frequently has other meanings. 202 2.4. Originator Domain 204 The "Originator Domain" is everything to the right of the "@" in the 205 Originator Address (excluding the "@" itself). 207 2.5. Alleged Signer 209 An "Alleged Signer" is the identity of the signer claimed in a DKIM- 210 Signature header field in a message received by a Verifier; it is 211 "alleged" because it has not yet been verified. 213 2.6. Alleged Originator 215 An "Alleged Originator" is the Originator Address of a message 216 received by a Verifier; it is "alleged" because it has not yet been 217 verified. 219 2.7. Sender Signing Practices 221 "Sender Signing Practices" (or just "practices") consist of a 222 machine-readable record published by the domain of the Alleged 223 Originator which includes information about whether or not that 224 domain signs all of their email, and whether signatures from third 225 parties are sanctioned by the Alleged Originator. 227 2.8. Originator Signature 229 An "Originator Signature" is any Valid Signature where the signing 230 address (listed in the "i=" tag if present, otherwise its default 231 value, consisting of the null address, representing an unknown user, 232 followed by "@", followed by the value of the "d=" tag) matches the 233 Originator Address. If the signing address does not include a local- 234 part, then only the domains must match; otherwise, the two addresses 235 must be identical. 237 2.9. Suspicious 239 Messages that do not contain a valid Originator Signature and which 240 are inconsistent with a Sender Signing Practices check (e.g., are 241 received without a Valid Signature and the sender's signing practices 242 indicate all messages from the domain are signed) are referred to as 243 "Suspicious". The handling of such messages is at the discretion of 244 the Verifier or final recipient. "Suspicious" applies only to the 245 DKIM evaluation of the message; a Verifier may decide the message 246 should be accepted on the basis of other information beyond the scope 247 of this document. Conversely, messages not deemed Suspicious may be 248 rejected for other reasons. 250 2.10. Third-Party Signature 252 A "Third-Party Signature" is a Valid Signature which is not an 253 Originator Signature. 255 2.11. Verifier Acceptable Third-Party Signature 257 A Verifier Acceptable Third-Party Signature is a Third-Party 258 Signature that the Verifier is willing to accept as meaningful for 259 the message under consideration. The Verifier may use any criteria 260 it deems appropriate for making this determination. 262 3. Operation Overview 264 Sender Signing Practices checks MUST be based on the Originator 265 Address. If the message contains a valid Originator Signature, no 266 Sender Signing Practices check need be performed: the Verifier 267 SHOULD NOT look up the Sender Signing Practices and the message MUST 268 NOT be considered Suspicious. 270 Verifiers checking messages that do not have at least one valid 271 Originator Signature MUST perform a Sender Signing Practices check on 272 the domain specified by the Originator Address as described in 273 Section 4.4. 275 A Sender Signing Practices check produces one of four possible 276 results: 278 1. Some messages from this domain are not signed; the message MUST 279 NOT be considered Suspicious, even in the absence of a valid 280 signature. This is the default. 282 2. All messages from this domain are signed. Messages containing a 283 Verifier Acceptable Third-Party Signature MUST NOT be considered 284 Suspicious. 286 NON-NORMATIVE RATIONALE: Third-party signatures, since they 287 can potentially represent any domain, are considered more 288 likely to be abused by attackers seeking to spoof a specific 289 address. It may therefore be desirable for verifiers to apply 290 other criteria outside the scope of this specification in 291 deciding to accept a given third-party signature. For 292 example, a list of known mailing list domains used by 293 addresses served by the verifier might be specifically 294 considered acceptable third-party signers. 296 3. All valid messages from this domain are signed; the domain of the 297 Alleged Originator requests that only messages with valid 298 Originator Signatures be considered not Suspicious; Third-Party 299 Signatures are irrelevant. This practice would typically be used 300 by domains which send only transactional email (i.e., do not use 301 mailing lists and such that are likely to break signatures) and 302 which wish to emphasize security over deliverability of their 303 messages. In the absence of a valid Originator Signature, the 304 message MUST be considered Suspicious. 306 4. The domain does not exist; the message MUST be considered 307 Suspicious. 309 If the Sender Signing Practices record for the domain does not exist 310 but the domain does exist, Verifier systems MUST assume that some 311 messages from this domain are not signed and the message MUST NOT be 312 considered Suspicious. 314 4. Detailed Description 316 4.1. DNS Representation 318 Sender Signing Practices records are published using the DNS TXT 319 resource record type. 321 NON-NORMATIVE DISCUSSION: There has been considerable discussion 322 on the DKIM WG mailing list regarding the relative advantages of 323 TXT and a new resource record (RR) type. Many DNS server and 324 resolver implementations are incapable of quickly and easily 325 supporting new resource record types. For this reason, support of 326 TXT records is required whether a new RR type is defined or not. 327 However, without a "flag day" on which SSP TXT record support is 328 to be withdrawn, such support is likely to continue indefinitely. 329 As a result, this specification defines no new RR type for SSP. 331 Another alternative proposed by P. Hallam-Baker is the publication 332 of both a TXT record and, when implementations permit, a new RR, 333 referred to as XPTR, which gives the location from which SSP and 334 other policy information relating to a give domain can be 335 retrieved. This has the advantage of supporting a variety of 336 policies in a scalable manner, with better handling of wildcards 337 and centralized publication of policy records, with caching 338 advantages. However, the above implementation issues also apply 339 to XPTR, and an additional lookup is required to retrieve SSP via 340 the XPTR method. At the time of publication of this draft, 341 consensus on this proposal was unclear. 343 The RDATA for SSP resource records is textual in format, with 344 specific syntax and semantics relating to their role in describing 345 sender signing practices. The "Tag=Value List" syntax described in 346 section 3.2 of [RFC4871] is used. Records not in compliance with 347 that syntax or the syntax of individual tags described in Section 4.3 348 MUST be ignored (considered equivalent to a NODATA result) for 349 purposes of message disposition, although they MAY cause the logging 350 of warning messages via an appropriate system logging mechanism. 352 SSP records for a domain are published at a location in the domain's 353 DNS hierarchy prefixed by _ssp._domainkey; e.g., the SSP record for 354 example.com would be a TXT record that is published at 355 _ssp._domainkey.example.com. 357 4.2. Publication of SSP Records 359 Sender Signing Practices are intended to apply to all mail sent from 360 the domain of an Alleged Originator, and to the greatest extent 361 possible, to all subdomains of that domain. There are several cases 362 that need to be considered in that regard: 364 o The domain itself 366 o Subdomains which may or may not be used for email 368 o Hostnames which may or may not be used for email 370 o Other named resource records in the domain 372 o Multi-level examples of the above, e.g., a.b.example.com 374 o Non-existent cases, i.e., a subdomain or hostname that does not 375 actually exist within the domain 377 Normally, a domain expressing Sender Signing Practices will want to 378 do so for both itself and all of its "descendents" (child domains and 379 hosts, at all lower levels). Domains wishing to do so MUST publish 380 SSP records as follows: 382 Publish an SSP record for the domain itself 384 Publish an SSP record for any existing subdomain 386 Note that since the lookup algorithm described below references the 387 immediate parent of the alleged originating domain, it is not 388 necessary to publish SSP records for every single-level label within 389 the domain. This has been done to relieve domain administrators of 390 the burden of publishing an SSP record for every other record in the 391 domain, which would be otherwise required. 393 Wildcards within a domain, including but not limited to wildcard MX 394 records, pose a particular problem. While referencing the immediate 395 parent domain allows the discovery of an SSP record corresponding to 396 an unintended immediate-child subdomain, wildcard records apply at 397 multiple levels. For example, if there is a wildcard MX record for 398 example.com, the domain foo.bar.example.com can receive mail through 399 the named mail exchanger. Conversely, the existence of the record 400 makes it impossible to tell whether foo.bar.example.com is a 401 legitimate name since a query for that name will not return an 402 NXDOMAIN error. For that reason, SSP coverage for subdomains of 403 domains containing a wildcard record is incomplete. 405 NON-NORMATIVE NOTE: Complete SSP coverage of domains containing 406 (or where any parent contains) wildcards generally cannot be 407 guaranteed. 409 4.3. Record Syntax 411 SSP records follow the "tag=value" syntax described in section 3.2 of 412 [RFC4871]. The SSP record syntax is a tag-list as defined in that 413 section, including the restriction on duplicate tags, the use of 414 white space, and case sensitivity. 416 Tags used in SSP records are as follows. Unrecognized tags MUST be 417 ignored. In the ABNF below, the FWS token is inherited from 418 [RFC2822] with the exclusion of obs-FWS. The ALPHA and DIGIT tokens 419 are imported from [RFC4234]. 421 dkim= Outbound signing practices for the domain (plain-text; 422 REQUIRED). Possible values are as follows: 424 unknown The domain may sign some or all email. 426 all All mail from the domain is signed; unsigned email MUST be 427 considered Suspicious. The domain may send messages through 428 agents that may modify and re-sign messages, so email signed 429 with a Verifier Acceptable Third-Party Signature SHOULD NOT be 430 considered Suspicious. 432 strict All mail from the domain is signed; messages lacking a 433 valid Originator Signature MUST be considered Suspicious. The 434 domain does not expect to send messages through agents that may 435 modify and re-sign messages. 437 NON-NORMATIVE RATIONALE: Strict practices may be used by 438 entities which send only transactional email to individual 439 addresses and which are willing to accept the consequence of 440 having some mail which is re-signed appear suspicious in 441 return for additional control over their addresses. Strict 442 practices may also be used by entities which do not send 443 (and therefore do not sign) any email. 445 ABNF: 447 ssp-dkim-tag = "dkim" [FWS] "=" [FWS] ("unknown" / 448 "all" / "strict") 450 handling= Non-compliant message handling request for the domain 451 (plain-text; OPTIONAL). Possible values are as follows: 453 process Messages which are Suspicious from this domain SHOULD be 454 processed by the verifier, although the SSP failure MAY be 455 considered in subsequent evaluation of the message. This is 456 the default value. 458 deny Messages which are Suspicious from this domain MAY be 459 rejected, bounced, or otherwise not delivered at the option of 460 the verifier. 462 NON-NORMATIVE EXPLANATION: The "deny" practice is intended 463 for use by domains that value security over deliverability. 464 For example, a domain used by a financial institution to 465 send transactional email, which signs all of its messages, 466 might consider their concern about phishing messages 467 purporting to come from their domain to be higher than their 468 concern about some some legitimate messages not being 469 delivered. The "handling=deny" practice allows them to 470 express that concern in a way that can be acted upon by 471 verifiers, if they so choose. 473 ABNF: 475 ssp-handling-tag = "handling" [FWS] "=" [FWS] ("process" / 476 "deny") 478 t= Flags, represented as a colon-separated list of names (plain-text; 479 OPTIONAL, default is that no flags are set). Flag values are: 481 y The domain is testing signing practices, and the Verifier 482 SHOULD NOT consider a message suspicious based on the record. 484 s The signing practices apply only to the named domain, and not 485 to subdomains. 487 ABNF: 489 ssp-t-tag = %x75 [FWS] "=" [FWS] ssp-t-tag-flag 490 0*( [FWS] ":" [FWS] ssp-t-tag-flag ) 491 ssp-t-tag-flag = "y" / "s" / hyphenated-word 492 ; for future extension 493 hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") 494 (ALPHA / DIGIT) ] 496 Unrecognized flags MUST be ignored. 498 4.4. Sender Signing Practices Check Procedure 500 Verifiers MUST produce a result that is semantically equivalent to 501 applying the following steps in the order listed. In practice, 502 several of these steps can be performed in parallel in order to 503 improve performance. 505 1. If a valid Originator Signature exists, the message is not 506 Suspicious, and the algorithm terminates. 508 2. The Verifier MUST query DNS for a TXT record corresponding to 509 the Originator Domain prefixed by "_ssp._domainkey.". If the 510 result of this query is a NOERROR response with one or more 511 answers which are syntactically-valid SSP responses, proceed to 512 step 7. 514 3. The Verifier MUST query DNS for an MX record corresponding to 515 the Originator Domain (with no prefix). This query is made only 516 to check the existence of the domain name and MAY be done in 517 parallel with the query made in step 2. If the result of this 518 query is an NXDOMAIN error, the message is Suspicious and the 519 algorithm terminates. 521 NON-NORMATIVE DISCUSSION: Any resource record type could be 522 used for this query since the existence of a resource record 523 of any type will prevent an NXDOMAIN error. The choice of MX 524 for this purpose is because this record type is thought to be 525 the most common for likely domains, and will therefore result 526 in a result which can be more readily cached than a negative 527 result. 529 4. If the immediate parent of the Originator Domain is a top-level 530 domain (a domain consisting of a single element such as "com", 531 "us", or "jp"), then the message is not Suspicious (because no 532 SSP record was found) and the algorithm terminates. The 533 verifier MAY also compare the parent domain against a locally- 534 maintained list of known address suffixes (e.g., .co.uk) and 535 terminate the algorithm with a not Suspicious result if the 536 parent domain matches an entry on the list. 538 5. The Verifier MUST query DNS for a TXT record for the immediate 539 parent domain, prefixed with "_ssp._domainkey." If the result 540 of this query is a NOERROR response with one or more answers 541 which are syntactically-valid SSP responses, proceed to step 6. 542 Otherwise, the message is not Suspicious and the algorithm 543 terminates. 545 6. If the SSP "t" tag exists in the response and any of the flags 546 is "s" (indicating it should not apply to a subdomain), the 547 message is not Suspicious and the algorithm terminates. 549 7. If the SSP "t" tag exists in the response and any of the flags 550 is "y" (indicating testing), the message is not Suspicious and 551 the algorithm terminates. 553 8. If the value of the SSP "dkim" tag is "unknown", the message is 554 not Suspicious and the algorithm terminates. 556 9. If the value of the SSP "dkim" tag is "all", and one or more 557 Verifier Acceptable Third-Party Signatures are present on the 558 message, the message is not Suspicious and the algorithm 559 terminates. 561 10. The message is Suspicious and the algorithm terminates. 563 If any of the queries involved in the Sender Signing Practices Check 564 result in a SERVFAIL error response, the verifier MAY either queue 565 the message or return an SMTP error indicating a temporary failure. 567 5. IANA Considerations 569 IANA is requested to create a "DKIM selector name" registry and to 570 reserve the selector name "_ssp" to avoid confusion between DKIM key 571 records and SSP records. 573 6. Security Considerations 575 Security considerations in the Sender Signing Practices are mostly 576 related to attempts on the part of malicious senders to represent 577 themselves as other senders, often in an attempt to defraud either 578 the recipient or the Alleged Originator. 580 Additional security considerations regarding Sender Signing Practices 581 may be found in the DKIM threat analysis [RFC4686]. 583 6.1. Fraudulent Sender Address 585 [[Assuming 3rd party signature is based on Sender header field]] If 586 the Sender Signing Practices sanction third-party signing, an 587 attacker can create a message with a From header field of an 588 arbitrary sender and a legitimately signed Sender header field 590 6.2. DNS Attacks 592 An attacker might attack the DNS infrastructure in an attempt to 593 impersonate SSP records. However, such an attacker is more likely to 594 attack at a higher level, e.g., redirecting A or MX record lookups in 595 order to capture traffic that was legitimately intended for the 596 target domain. Domains concerned about this should use DNSSEC 597 [RFC4033]. 599 Because SSP operates within the framework of the legacy e-mail 600 system, the default result in the absence of an SSP record is that 601 the domain does not sign all of its messages. Therefore, a DNS 602 attack which is successful in suppressing the SSP response to the 603 verifier is sufficient to cause the verifier to see unsigned messages 604 as non-suspicious, even when that is not intended by the alleged 605 originating domain. 607 7. References 609 7.1. Normative References 611 [RFC1035] Mockapetris, P., "Domain names - implementation and 612 specification", STD 13, RFC 1035, November 1987. 614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 615 Requirement Levels", BCP 14, RFC 2119, March 1997. 617 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 618 April 2001. 620 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 621 Specifications: ABNF", RFC 4234, October 2005. 623 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 624 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 625 Signatures", RFC 4871, May 2007. 627 7.2. Informative References 629 [I-D.ietf-dkim-ssp-requirements] 630 Thomas, M., "Requirements for a DKIM Signing Practices 631 Protocol", draft-ietf-dkim-ssp-requirements-05 (work in 632 progress), April 2007. 634 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 635 Rose, "DNS Security Introduction and Requirements", 636 RFC 4033, March 2005. 638 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys 639 Identified Mail (DKIM)", RFC 4686, September 2006. 641 Appendix A. Acknowledgements 643 The authors wish to thank many members of the ietf-dkim mailing list, 644 in particular Arvel Hathcock and Eliot Lear, for valuable suggestions 645 and constructive criticism of earlier versions of this draft. 647 Appendix B. Change Log 649 B.1. Changes since -ietf-dkim-ssp-00 651 o Clarified Operation Overview and eliminated use of Legitimate as 652 the counterpart of Suspicious since the words have different 653 meanings. 655 o Improved discussion (courtesy of Arvel Hathcock) of the use of TXT 656 records in DNS vs. a new RR type. 658 o Clarified publication rules for multilevel names. 660 o Better description of overall record syntax, in particular that 661 records with unknown tags are considered syntactically correct. 663 o Clarified Sender Signing Practices Check Procedure, primarily by 664 use of new term Originator Domain. 666 o Eliminated section "Third-Party Signatures and Mailing Lists" that 667 is better included in the DKIM overview document. 669 o Added "handling" tag to express alleged sending domain's 670 preference about handling of Suspicious messages. 672 o Clarified handling of SERVFAIL error in SSP check. 674 o Replaced "entity" with "domain", since with the removal of user- 675 granularity SSP, the only entities having sender signing policies 676 are domains. 678 B.2. Changes since -allman-ssp-02 680 o Removed user-granularity SSP and u= tag. 682 o Replaced DKIMP resource record with a TXT record. 684 o Changed name of the primary tag from "p" to "dkim". 686 o Replaced lookup algorithm with one which traverses upward at most 687 one level. 689 o Added description of records which must be published, and effect 690 of wildcard records within the domain, on SSP. 692 B.3. Changes since -allman-ssp-01 694 o Changed term "Sender Signing Policy" to "Sender Signing 695 Practices". 697 o Changed query methodology to use a separate DNS resource record 698 type, DKIMP. 700 o Changed tag values from SPF-like symbols to words. 702 o User level policies now default to that of the domain if not 703 specified. 705 o Removed the "Compliance" section since we're still not clear on 706 what goes here. 708 o Changed the "parent domain" policy to only search up one level 709 (assumes that subdomains will publish SSP records if appropriate). 711 o Added detailed description of SSP check procedure. 713 B.4. Changes since -allman-ssp-00 715 From a "diff" perspective, the changes are extensive. Semantically, 716 the changes are: 718 o Added section on "Third-Party Signatures and Mailing Lists" 719 o Added "Compliance" (transferred from -base document). I'm not 720 clear on what needs to be done here. 722 o Extensive restructuring. 724 Authors' Addresses 726 Eric Allman 727 Sendmail, Inc. 728 6475 Christie Ave, Suite 350 729 Emeryville, CA 94608 730 USA 732 Phone: +1 510 594 5501 733 Email: eric+dkim@sendmail.org 734 URI: 736 Mark Delany 737 Yahoo! Inc. 738 701 First Avenue 739 Sunnyvale, CA 94089 740 USA 742 Phone: +1 408 349 6831 743 Email: markd+dkim@yahoo-inc.com 744 URI: 746 Jim Fenton 747 Cisco Systems, Inc. 748 MS SJ-9/2 749 170 W. Tasman Drive 750 San Jose, CA 95134-1706 751 USA 753 Phone: +1 408 526 5914 754 Email: fenton@cisco.com 755 URI: 757 Full Copyright Statement 759 Copyright (C) The IETF Trust (2007). 761 This document is subject to the rights, licenses and restrictions 762 contained in BCP 78, and except as set forth therein, the authors 763 retain all their rights. 765 This document and the information contained herein are provided on an 766 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 767 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 768 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 769 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 770 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 771 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 773 Intellectual Property 775 The IETF takes no position regarding the validity or scope of any 776 Intellectual Property Rights or other rights that might be claimed to 777 pertain to the implementation or use of the technology described in 778 this document or the extent to which any license under such rights 779 might or might not be available; nor does it represent that it has 780 made any independent effort to identify any such rights. Information 781 on the procedures with respect to rights in RFC documents can be 782 found in BCP 78 and BCP 79. 784 Copies of IPR disclosures made to the IETF Secretariat and any 785 assurances of licenses to be made available, or the result of an 786 attempt made to obtain a general license or permission for the use of 787 such proprietary rights by implementers or users of this 788 specification can be obtained from the IETF on-line IPR repository at 789 http://www.ietf.org/ipr. 791 The IETF invites any interested party to bring to its attention any 792 copyrights, patents or patent applications, or other proprietary 793 rights that may cover technology that may be required to implement 794 this standard. Please address the information to the IETF at 795 ietf-ipr@ietf.org. 797 Acknowledgment 799 Funding for the RFC Editor function is provided by the IETF 800 Administrative Support Activity (IASA).