idnits 2.17.1 draft-ietf-dkim-ssp-requirements-05.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 677. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 695. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 701. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (August 11, 2007) is 6096 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 4871 (Obsoleted by RFC 6376) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DKIM Working Group M. Thomas 3 Internet-Draft Cisco Systems 4 Intended status: Informational August 11, 2007 5 Expires: February 12, 2008 7 Requirements for a DKIM Signing Practices Protocol 8 draft-ietf-dkim-ssp-requirements-05 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on February 12, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism 42 for domains to assert responsibility for the messages they handle. A 43 related mechanism will allow an administrator to publish various 44 statements about their DKIM signing practices. This document defines 45 requirements for this mechanism, distinguishing between those that 46 must be satisified (MUST), and those that are highly desirable 47 (SHOULD). 49 Requirements Language 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [RFC2119]. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. SSP Problem Scenarios . . . . . . . . . . . . . . . . . . . . 7 62 3.1. Problem Scenario 1: Is All Mail Signed with DKIM? . . . . 7 63 3.2. Problem Scenario 2: Illegitimate Domain Name Use . . . . . 8 65 4. SSP Deployment Considerations . . . . . . . . . . . . . . . . 10 66 4.1. Deployment Consideration 1: Outsourced Signing . . . . . . 10 67 4.2. Deployment Consideration 2: Subdomain Coverage . . . . . . 10 68 4.3. Deployment Consideration 3: Resent Original Mail . . . . . 10 69 4.4. Deployment Consideration 4: Incremental Deployment of 70 Signing . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 4.5. Deployment Consideration 5: Performance and Caching . . . 11 72 4.6. Deployment Consideration 6: Human Legibility of 73 Practices . . . . . . . . . . . . . . . . . . . . . . . . 12 74 4.7. Deployment Consideration 7: Extensibility . . . . . . . . 12 75 4.8. Deployment Consideration 8: Security . . . . . . . . . . . 12 77 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 5.1. Discovery Requirements . . . . . . . . . . . . . . . . . . 13 79 5.2. SSP Transport Requirements . . . . . . . . . . . . . . . . 14 80 5.3. Practice and Expectation Requirements . . . . . . . . . . 14 81 5.4. Extensibility and Forward Compatibility Requirements . . . 16 83 6. Requirements for SSP Security . . . . . . . . . . . . . . . . 18 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 89 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 93 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 96 Intellectual Property and Copyright Statements . . . . . . . . . . 24 98 1. Introduction 100 DomainKeys Identified Mail [RFC4871] defines a message level signing 101 and verification mechanism for email. While a DKIM signed message 102 speaks for itself, there is ambiguity if a message doesn't have a 103 valid first party signature (ie, on behalf of the [RFC2822].From 104 address): is this to be expected or not? For email this is an 105 especially difficult problem since there is no expectation of a 106 priori knowledge of a sending domain's practices. This ambiguity can 107 be used to mount a bid down attack that is inherent with systems like 108 email that allow optional authentication: if a receiver doesn't know 109 otherwise, it should not assume that the lack of a valid signature is 110 exceptional without other information. Thus, an attacker can take 111 advantage of the ambiguity and simply not sign messages. If a 112 protocol could be developed for a domain to publish its DKIM signing 113 practices, a message verifier could take that into account when it 114 receives an unsigned piece of email. 116 This document defines the requirements for a mechanism that permits 117 the publication of Sender Signing Practices (SSP). The document is 118 organized into two main sections: a Problem and Deployment Scenario 119 section which describes the problems that SSP is intended to address 120 as well as the deployment issues surrounding the base problems. The 121 second section is the Requirements that arise because of those 122 scenarios. 124 2. Definitions 126 o Domain Holder: the entity that controls the contents of the DNS 127 subtree starting at the domain, either directly or by delegation 128 via NS records it controls. 130 o First Party Address: For DKIM, a first party address is defined to 131 be the [RFC2822].From address in the message header; a first party 132 address is also known as an Author address 134 o First Party Signature: a first party signature is a valid 135 signature where the signing identity (the d= tag or the more 136 specific identity i= tag) matches the first party address. 137 "Matches" in this context is defined in [RFC4871]. 139 o Third Party Signature: a third party signature is a valid 140 signature that does not qualify as a First Party Signature. Note 141 that a DKIM third party signature is not required to correspond to 142 a header field address such as the contents of Sender or List-Id, 143 etc. 145 o Practice: a statement according to the [RFC2822].From domain 146 holder of externally verifiable behavior in the email messages it 147 sends. 149 o Expectation: an Expectation combines with a Practice to convey 150 what the domain holder considers the likely survivability of the 151 Practice for a receiver, in particular receivers that may be more 152 than one SMTP hop away. 154 o DKIM Signing Complete: a Practice where the domain holder asserts 155 that all legitimate mail will be sent with a valid First Party 156 Signature. 158 3. SSP Problem Scenarios 160 The email world is a diverse place with many deployment 161 considerations. This section outlines expected usage scenarios where 162 DKIM signing/verifying will take place, and how a new protocol might 163 help to clarify the relevance of DKIM-signed mail. 165 3.1. Problem Scenario 1: Is All Mail Signed with DKIM? 167 After auditing their outgoing mail and deploying DKIM signing for all 168 of their legitimate outgoing mail, a domain could be said to be DKIM 169 signing complete. That is, the domain has to the best of its ability 170 ensured that all legitimate mail purporting to have come from that 171 domain contains a valid DKIM signature. 173 A receiver in the general case doesn't know what the practices are 174 for a given domain. Thus, the receiver is at a disadvantage in not 175 knowing whether it should expect all mail to be signed from a given 176 domain or not. This knowledge gap leads to a trivially exploitable 177 bid-down attack where the attacker merely sends unsigned mail; since 178 the receiver doesn't know the practices of the signing domain, it 179 cannot treat the message any more harshly for lack of a valid 180 signature. 182 An information service which allows a receiver to query for the 183 practices and expectations of the first party domain when no valid 184 first party signature is found could be useful in closing this gap. 185 A receiver could use this information to treat such questionable mail 186 with varying degrees of prejudice. 188 Note that for the foreseeable future, unrestricted use patterns of 189 mail (eg where users may be members of mailing lists, etc) will 190 likely suffer occasional non-malicious signature failure in transit. 191 While probably not a large percentage of total traffic, the kind of 192 breakage may be a significant concern for those usage patterns. This 193 scenario defines where the sender cannot set any expectation as to 194 whether an individual message will arrive intact. 196 Even without that expectation, a receiver may be able to take 197 advantage of the knowledge that the domain's practice is to sign all 198 mail and bias its filters against unsigned or damaged in transit 199 mail. This information should not be expected to be used in a binary 200 yes/no fashion, but instead as a data point among others in a 201 filtering system. 203 The following exchange illustrates problem scenario 1. 205 1. Mail with a [RFC2822].From domain Alice is sent to domain Bob 206 with a missing or broken DKIM first party signature from Alice 208 2. Domain Bob would like to know whether that is an expected state 209 of affairs. 211 3. Domain Alice provides information that it signs all outgoing 212 mail, but places no expectation on whether it will arrive with an 213 intact first party signature. 215 4. Domain Bob could use this information to bias its filters to 216 examines the message with some suspicion. 218 3.2. Problem Scenario 2: Illegitimate Domain Name Use 220 A class of mail typified by transactional mail from high value 221 domains is currently the target of phishing attacks. In particular, 222 many phishing scams forge the [RFC2822].From address in addition to 223 spoofing much of the content to trick unsuspecting users into 224 revealing sensitive information. Domain holders sending this mail 225 would like the ability to give an enhanced guarantee that mail sent 226 with their domain name should always arrive with the proof that the 227 domain holder consented to its transmission. That is, the message 228 should contain a valid first party signature as defined above. 230 From a receiver's standpoint, knowing that a domain not only signs 231 all of its mail, but places a very high value on the receipt of a 232 valid first party signature from that domain is helpful. Hence a 233 receiver can know that the domain not only signs all of its mail, but 234 also feels it essential that legitimate mail must have its first 235 party signatures survive transit. A receiver with the knowledge of 236 the sender's expectations in hand might choose to process messages 237 not conforming to the published practices in a special manner. Note 238 that the ability to state an enhanced guarantee of a valid signature 239 means that senders should expect mail that traverses modifying 240 intermediaries (eg, mailing lists, etc) will be likely be quarantined 241 or deleted, thus this scenario is more narrow than problem scenario 242 1. 244 [Informative Note: a receiving filter may choose to treat scenario 245 2 much more harshly than scenario 1; where scenario 1 looks odd, 246 scenario 2 looks like something is very wrong] 248 1. Mail with a [RFC2822].From domain Alice is sent to domain Bob 249 with a missing or broken first party DKIM signature from domain 250 Alice 252 2. Domain Bob would like to know whether that is an expected state 253 of affairs. 255 3. Domain Alice provides information that it signs all outgoing 256 mail, and furthermore places an expectation that it should arrive 257 with an intact first party signature, and that the receiver 258 should be much more wary if it does not. 260 4. Domain Bob could use this information to bias its filters such 261 that it examines the message with great suspicion. 263 4. SSP Deployment Considerations 265 Given the problems enumerated above for which we'd like SSP to 266 provide information to recipients, there are a number of scenarios 267 that are not related to the problems that are to be solved, per se, 268 but the actual mechanics of implementing/deploying the information 269 service that SSP would provide. 271 4.1. Deployment Consideration 1: Outsourced Signing 273 Many domains do not run their own mail infrastructure, or may 274 outsource parts of it to third parties. It is desirable for a domain 275 holder to have the ability delegate to other entities the ability to 276 sign for the domain holder. One obvious use scenario is a domain 277 holder from a small domain that needs to have the ability for their 278 outgoing ISP to sign all of their mail on behalf of the domain 279 holder. Other use scenarios include outsourced bulk mail for 280 marketing campaigns, as well as outsourcing various business 281 functions such as insurance benefits, etc. 283 4.2. Deployment Consideration 2: Subdomain Coverage 285 A SSP client will perform lookups on incoming mail streams to provide 286 the information as proposed in the problem scenarios. The domain 287 part of the first address of the [RFC2822].From will form the basis 288 to fetch the published information. A trivial attack to circumvent 289 finding the published information can be mounted by simply using a 290 subdomain of the parent domain which doesn't have published 291 information. This attack is called the subdomain attack: that is, a 292 domain wants to not only publish a policy for a given DNS label it 293 controls, but it would also like to protect all subdomains of that 294 label as well. If this characteristic is not met, an attacker would 295 need only create a possibly fictitious subdomain that was not covered 296 by SSP's information service. Thus, it would be advantageous for SSP 297 to not only cover a given domain, but all subdomains of that domain 298 as well. 300 4.3. Deployment Consideration 3: Resent Original Mail 302 Resent mail is a common occurrence in many scenarios in the email 303 world of today. For example, domain Alice sends a DKIM signed 304 message with a published practice of signing all messages to domain 305 Bob's mailing list. Bob, being a good net citizen, wants to be able 306 to take his part of the responsibility of the message in question, so 307 he DKIM signs the message, perhaps corresponding to the Sender 308 address. 310 Note that this scenario is completely orthogonal to whether Alice's 311 signature survived Bob's mailing list: Bob merely wants to assert his 312 part in the chain of accountability for the benefit of the ultimate 313 receivers. It would be useful for this practice to be encouraged as 314 it gives a more accurate view of who handled the message. It also 315 has the side benefit that remailers that are not friendly to DKIM 316 first party signatures (ie, break them) can be potentially assessed 317 by the receiver based on the receiver's opinion of the signing 318 domains that actually survived. 320 4.4. Deployment Consideration 4: Incremental Deployment of Signing 322 As a practical matter, it may be difficult for a domain to roll out 323 DKIM signing such that they can publish the DKIM Signing Complete 324 practice given the complexities of the user population, outsourced 325 vendors sending on its behalf, etc. This leaves open an exploit that 326 high-value mail such as in Problem Scenario 2 must be classified to 327 the least common denominator of the published practices. It would be 328 desirable to allow a domain holder to publish a list of exceptions 329 which would have a more restrictive practices statement. NB: this 330 consideration has been deemed met by the mechanisms provided by the 331 base DKIM signing mechanism; it is merely documented here as having 332 been an issue. 334 For example, bigbank.example.com might be ready to say that 335 statements@bigbank.example.com is always signed, but the rest of the 336 domain, say, is not. Another situation is that the practices of some 337 address local parts in a given domain are not the same as practices 338 of other local parts. Using the same example of 339 statements@bigbank.example.com being a transactional kind of email 340 which would like to publish very strong practices, mixed in with the 341 rest of the user population local parts which may go through mailing 342 lists, etc, for which a less strong statement is appropriate. 344 It should be said that DKIM, through the use of subdomains, can 345 already support this kind of differentiation. That is, in order to 346 publish a strong practice, one only has to segregate those cases into 347 different subdomains. For example: accounts.bigbank.example.com 348 would publish constrained practices while 349 corporateusers.bigbank.example.com might publish more permissive 350 practices. 352 4.5. Deployment Consideration 5: Performance and Caching 354 Email service provides an any-any mesh of potential connections: all 355 that is required is the publication of an MX record and a SMTP 356 listener to receive mail. Thus the use of SSP is likely to fall into 357 two main scenarios, the first of which are large, well known domains 358 who are in constant contact with one another. In this case caching 359 of records is essential for performance, including the caching of the 360 non-existence of records (ie, negative caching). 362 The second main scenario is when a domain exchanges mail with a much 363 smaller volume domain. This scenario can be both perfectly normal as 364 with the case of vanity domains, and unfortunately a vector for those 365 sending mail for anti-social reasons. In this case we'd like the 366 message exchange burden to SSP querier to be low, since many of the 367 lookups will not provide a useful answer. Likewise, it would be 368 advantageous to have upstream caching here as well so that, say, a 369 mailing list exploder on a small domain does not result in an 370 explosion of queries back at the root and authoritative server for 371 the small domain. 373 4.6. Deployment Consideration 6: Human Legibility of Practices 375 While SSP records are likely to be primarily consumed by an 376 automaton, for the foreseeable future they are also likely to be 377 inspected by hand. It would be nice to have the practices stated in 378 a fashion which is also intuitive to the human inspectors. 380 4.7. Deployment Consideration 7: Extensibility 382 While this document pertains only to requirements surrounding DKIM 383 signing practices, it would be beneficial for the protocol to be able 384 to extend to other protocols. 386 4.8. Deployment Consideration 8: Security 388 SSP must be able to withstand life in a hostile open internet 389 environment. These include DoS attacks, and especially DoS attacks 390 that leverage themselves through amplification inherent in the 391 protocol. In addition, while a useful protocol may be built without 392 strong source authentication provided by the information service, a 393 path to strong source authentication should be provided by the 394 protocol, or underlying protocols. 396 5. Requirements 398 This section defines the requirements for SSP. As with most 399 requirements documents, these requirements define the MINIMUM 400 requirements that a candidate protocol must provide. It should also 401 be noted that SSP must fulfill all of the requirements. 403 5.1. Discovery Requirements 405 Receivers need a means of obtaining information about a sender's DKIM 406 practices. This requires a means of discovering where the 407 information is and what it contains. 409 1. The author is the first-party sender of a message, as specified 410 in the [RFC2822].From field. SSP's information is associated 411 with the author's domain name and is published subordinate to 412 that domain name. 414 2. In order to limit the cost of its use, any query service 415 supplying SSP's information MUST provide a definitive responsive 416 within a small, deterministic number of message exchanges under 417 normal operational conditions. 419 [Informative Note: this, for all intents and purposes is a 420 prohibition on anything that might produce loops or result in 421 extended delays and overhead; also though "deterministic" 422 doesn't specify how many exchanges, the expectation is "few".] 424 [Refs: Deployment Considerations 2, 5] 426 3. SSP's publishing mechanism MUST be defined such that it does not 427 lead to multiple resource records of the same type for different 428 protocols residing at the same location. 430 [Informative note: An example is multiple resource record of 431 the same type within a common DNS leaf. Hence, uniquely 432 defined leaf names or uniquely defined resource record types 433 will ensure unambiguous reference.] 435 [Refs: Deployment Consideration 2] 437 4. SSP retrieval SHOULD provide coverage for not only a given domain 438 but all of its subdomains as well. It is recognized that there 439 is some reasonable doubt about the feasibility of a widely 440 accepted solution to this requirement. If the working group does 441 not achieve rough consensus on a solution, it MUST document the 442 relevant security considerations in the protocol specification. 444 [Refs: Deployment Considerations 2, 5] 446 5.2. SSP Transport Requirements 448 The publication and query mechanism will operate as an an internet- 449 based message exchange. There are multiple requirements for this 450 lower layer service: 452 1. The exchange SHOULD have existing widespread deployment of the 453 transport layer, especially if riding on top of a true transport 454 layer (eg, TCP, UDP). 456 [Refs: Deployment Considerations 5, 7] 458 2. The query/response in terms of latency time and the number of 459 messages involved MUST be low (less than three message exchanges 460 not counting retransmissions or other exceptional conditions). 462 [Refs: Deployment Consideration 5] 464 3. If the infrastructure doesn't provide caching (a la DNS), the 465 records retrieved MUST provide initiators the ability maintain 466 their own cache. Existing caching infrastructure is, however, 467 highly desirable. 469 [Refs: Deployment Consideration 5] 471 4. Multiple geographically and topologically diverse servers MUST be 472 supported for high availability 474 [Refs: Deployment Considerations 5, 7] 476 5.3. Practice and Expectation Requirements 478 As stated in the definitions a Practice is a statement according to 479 the [RFC2822].From domain holder of externally verifiable behavior in 480 the email messages it sends. As an example, a Practice might be 481 defined that all email messages will contain a DKIM signature 482 corresponding to the [RFC2822].From address. Since there is a 483 possibility of alteration between what a sender sends and a receiver 484 examines, an Expectation combines with a Practice to convey what the 485 [RFC2822].From domain considers the likely outcome of the 486 survivability of the Practice at a receiver. For example, a Practice 487 that a valid DKIM for the [RFC2822].From address is present when it 488 is sent from the domain, and an Expectation that it will remain 489 present and valid for all receivers whether topologically adjacent or 490 not. 492 1. SSP MUST be able to make Practices and Expectation assertions 493 about the domain part of a [RFC2822].From address in the context 494 of DKIM. SSP will not make assertions about other addresses for 495 DKIM at this time. 497 [Refs: Problem Scenarios 1,2] 499 2. SSP MUST provide a concise linkage between the [RFC2822].From 500 and the identity in the DKIM i= tag, or its default if it is 501 missing in the signature. That is, SSP MUST precisely define 502 the semantics of what qualifies as a First Party Signature. 504 [Refs: Problem Scenarios 1,2] 506 3. SSP MUST be able to publish a Practice that the domain's signing 507 behavior is "DKIM Signing Complete". That is, all messages were 508 transmitted with a valid first party signature. 510 [Refs: Problem Scenario 1] 512 4. SSP MUST be able to publish an Expectation that a verifiable 513 first party DKIM Signature should be expected on receipt of a 514 message. 516 [Refs: Problem Scenario 2] 518 5. Practices and Expectations MUST be presented in SSP syntax using 519 as intuitive a descriptor as possible. For example, p=? would 520 be better represented as p=unknown. 522 [Refs: Deployment Consideration 6] 524 6. Because DKIM uses DNS to store selectors, there is always the 525 ability for a domain holder to delegate all or parts of the 526 _domainkey subdomain to an affiliated party of the domain 527 holder's choosing. That is, the domain holder may set an NS 528 record for _domainkey.example.com to delegate to an email 529 provider who manages the entire namespace. There is also the 530 ability for the domain holder to partition its namespace into 531 subdomains to further constrain third parties. For example, a 532 domain holder could delegate only 533 _domainkey.benefits.example.com to a third party to constrain 534 the third party to only be able to produce valid signatures in 535 the benefits.example.com subdomain. Last, a domain holder can 536 even use CNAME's to delegate individual leaf nodes. Given the 537 above considerations, SSP need not invent a different means of 538 allowing affiliated parties to sign on a domain's behalf at this 539 time. 541 [Refs: Deployment Consideration 4] 543 7. Practices and Expectations MUST be presented as an information 544 service from the signing domain to be consumed as an added 545 factor to the receiver's local policy. In particular, a 546 Practice or Expectation MUST NOT mandate any disposition stance 547 on the receiver. 549 [Refs: Problem Scenarios 1, 2] 551 8. There is no requirement that SSP publish a Practices of any/all 552 third parties that MUST NOT sign on the domain holder's behalf. 553 This should be considered out of scope. 555 [INFORMATIVE NOTE: this is essentially saying that the 556 protocol doesn't have to concern itself with being a 557 blacklist repository.] 559 [Refs: Problem Scenarios 1,2] 561 9. SSP MUST NOT be required to be invoked if a valid first party 562 signature is found. 564 [Refs: Deployment Consideration 2] 566 10. SSP MUST NOT provide a mechanism which impugns the existence of 567 non-first party signatures in a message. A corollary of this 568 requirement is that the protocol MUST NOT link practices of 569 first party signers with the practices of third party signers. 571 [INFORMATIVE NOTE: the main thrust of this requirement is 572 that practices should only be published for that which the 573 publisher has control, and should not meddle in what is 574 ultimately the local policy of the receiver.] 576 [Refs: Deployment Consideration 3] 578 5.4. Extensibility and Forward Compatibility Requirements 580 1. SSP MUST NOT extend to any other protocol than DKIM for email at 581 this time. SSP SHOULD be extensible for protocols other than 582 DKIM. 584 [Refs: Deployment Consideration 7] 586 2. SSP MUST be able to add new Practices and Expectations within the 587 existing discovery/transport/practices in a backward compatible 588 fashion. 590 [Refs: Deployment Consideration 7] 592 6. Requirements for SSP Security 594 1. SSP for a high-value domain is potentially a high-value DoS 595 target, especially since the unavailability of SSP's record could 596 make unsigned messages less suspicious. 598 2. SSP MUST NOT make highly leveraged amplification or make-work 599 attacks possible. In particular the work and message exchanges 600 involved MUST be order of a constant. 602 [Refs: Deployment Consideration 8] 604 3. SSP MUST have the ability for a domain holder to provide SSP's 605 data such that a receiver can determine that it is authentically 606 from the domain holder with a large degree of certainty. SSP may 607 provide means which provide less certainty in trade off for ease 608 of deployment. 610 [Refs: Deployment Consideration 8] 612 7. IANA Considerations 614 This document makes no request of IANA. 616 Note to RFC Editor: this section may be removed on publication as an 617 RFC. 619 8. Security Considerations 621 This document defines requirements for a new protocol and the 622 security related requirements are defined above. Since it is 623 expected that the new protocol will use the DNS as a basis for the 624 published SSP information, most if not all of the threats described 625 in [RFC4686] will be applicable. 627 9. Acknowledgments 629 Dave Crocker and Jim Fenton provided substantial review of this 630 document. Thanks also to Vijay Gurbani and David Harrington for 631 their helpful last call reviews. 633 10. References 635 10.1. Normative References 637 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 638 Requirement Levels", BCP 14, RFC 2119, March 1997. 640 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 641 April 2001. 643 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys 644 Identified Mail (DKIM)", RFC 4686, September 2006. 646 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 647 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 648 Signatures", RFC 4871, May 2007. 650 10.2. Informative References 651 Author's Address 653 Michael Thomas 654 Cisco Systems 655 606 Sanchez St 656 San Francisco, California 94114 657 USA 659 Phone: +1-408-525-5386 660 Fax: +1-408-525-5386 661 Email: mat@cisco.com 663 Full Copyright Statement 665 Copyright (C) The IETF Trust (2007). 667 This document is subject to the rights, licenses and restrictions 668 contained in BCP 78, and except as set forth therein, the authors 669 retain all their rights. 671 This document and the information contained herein are provided on an 672 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 673 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 674 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 675 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 676 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 677 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 679 Intellectual Property 681 The IETF takes no position regarding the validity or scope of any 682 Intellectual Property Rights or other rights that might be claimed to 683 pertain to the implementation or use of the technology described in 684 this document or the extent to which any license under such rights 685 might or might not be available; nor does it represent that it has 686 made any independent effort to identify any such rights. Information 687 on the procedures with respect to rights in RFC documents can be 688 found in BCP 78 and BCP 79. 690 Copies of IPR disclosures made to the IETF Secretariat and any 691 assurances of licenses to be made available, or the result of an 692 attempt made to obtain a general license or permission for the use of 693 such proprietary rights by implementers or users of this 694 specification can be obtained from the IETF on-line IPR repository at 695 http://www.ietf.org/ipr. 697 The IETF invites any interested party to bring to its attention any 698 copyrights, patents or patent applications, or other proprietary 699 rights that may cover technology that may be required to implement 700 this standard. Please address the information to the IETF at 701 ietf-ipr@ietf.org. 703 Acknowledgment 705 Funding for the RFC Editor function is provided by the IETF 706 Administrative Support Activity (IASA).