idnits 2.17.1 draft-santos-dkim-dsap-00.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 on line 1043. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1054. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1061. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1067. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (July 26, 2006) is 6456 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC2821' is defined on line 992, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) 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 H. Santos 3 Internet-Draft Santronics Software, Inc. 4 Intended status: Experimental July 26, 2006 5 Expires: January 27, 2007 7 DKIM Signature Authorization Protocol (DSAP) 8 draft-santos-dkim-dsap-00 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 January 27, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 DSAP (DKIM Signature Authorization Protocol) is a DNS-based security 42 protocol designed to complement the DKIM (DomainKeys Identified 43 Message) protocol. DSAP provides a simple to implement robust 44 security wrapper around DKIM message signing practices by offering 45 DKIM signature authorization controls. 47 To be Done List 49 1. Continue to fine tune introduction, background, if required. 50 2. Complete usages text and examples TXT records for all DSAP 51 Polices 52 3. Do we need the section 1.1 acroynms? 53 4. Simplify titles for DNS Policies sections. 54 5. Easier (combined) syntax for failure tags? f=a:value,s:value,x: 55 value? 56 6. Complete the security section. 58 Table of Contents 60 1. Nomemclature and Definitions . . . . . . . . . . . . . . . . . 4 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 62 1.2. Definitions and Acroynms . . . . . . . . . . . . . . . . . 4 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.1. Background: How did we get here? . . . . . . . . . . . . . 6 65 2.1.1. DKIM Protocol Overview . . . . . . . . . . . . . . . . 6 66 2.1.2. DKIM Security Issues . . . . . . . . . . . . . . . . . 7 67 2.1.3. DKIM Implementation Issues . . . . . . . . . . . . . . 8 68 3. Implementing DSAP . . . . . . . . . . . . . . . . . . . . . . 9 69 3.1. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.2. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 3.3. Mailing List Servers . . . . . . . . . . . . . . . . . . . 12 72 4. DSAP DNS Resource Record . . . . . . . . . . . . . . . . . . . 12 73 4.1. DSAP Tag: v=/ . . . . . . . . 13 74 4.2. DSAP Tags: op=; 3p=; . . . 14 75 4.3. DSAP Tag; 3pl=; . . . . . . . . . . . . . . . . 15 76 4.4. DSAP Tag: a= . . . . . . . . . . . . . . . 15 77 4.5. DSAP Tag: r= . . . . . . . . . . . . . . . 16 78 4.6. DSAP Tag: n= . . . . . . . . . . . . . . . . . . . . 16 79 4.7. DSAP Tag: t=y . . . . . . . . . . . . . . . . . . . . . . 16 80 4.8. DSAP Tags: fa=; 81 fs=; fx=; . . . . . . 16 82 4.9. Symbolic Semantics . . . . . . . . . . . . . . . . . . . . 17 83 5. DSAP Policies . . . . . . . . . . . . . . . . . . . . . . . . 18 84 5.1. No Mail Expected . . . . . . . . . . . . . . . . . . . . . 18 85 5.2. No Signature Expected . . . . . . . . . . . . . . . . . . 18 86 5.3. Only 3rd party Signature Expected . . . . . . . . . . . . 19 87 5.4. Only 3rd party Signature Expected, if any . . . . . . . . 19 88 5.5. Only Original Party Signature Expected . . . . . . . . . . 19 89 5.6. Original and 3rd party Signatures Expected . . . . . . . . 20 90 5.7. Original Party Signature Expected, 3rd party Optional . . 20 91 5.8. Only Original Party Signature Expected, if any . . . . . . 21 92 5.9. Original Party Optional, 3rd Party Signature Expected . . 21 93 5.10. Optional Original Party or 3rd Party Signatures . . . . . 21 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 97 7.1. Policy Attacks . . . . . . . . . . . . . . . . . . . . . . 22 98 7.2. Multiple Original Addresses . . . . . . . . . . . . . . . 22 99 7.3. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 22 100 7.4. Abuse Report Address Attacks . . . . . . . . . . . . . . . 22 101 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 103 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 104 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 105 Appendix A. DKIM-BASE Update Considerations . . . . . . . . . . . 23 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 107 Intellectual Property and Copyright Statements . . . . . . . . . . 24 109 1. Nomemclature and Definitions 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 1.2. Definitions and Acroynms 119 MTA Mail Transfer Agent. Sender or Receiver of mail. 120 Generally viewed as a router within a MSA intra- 121 network where there is a inherent authentication. 123 MUA Mail User Agent. Online or offline mail reader/writer 124 software. Typically has its own MTA component for 125 sending mail. 127 MSA Mail Submission Agent. Generally associated with a 128 MUA sending message to a ISP or ESP where there is an 129 authorized or authenticated association with the MUA. 131 MDA Mail Destination Agent. Generally associated as the 132 final destination of the message where the message is 133 typically targeted for a local user. If the MDA is 134 going to route the mail, then its behavioring more as 135 a MSA or MTA. 137 MFA Mail Filtering Agent. Generally associated with a 138 post reception process which mayl analyze the payload 139 for local policy filtering requirements. 141 MLS Mailing List Server. MLS may have a built-in MTA but 142 generally are standalone processes working in 143 conjunction with other MTA processes. 145 SIGNATURE In the context of this document, DKIM signatures are 146 the only signatures described. 148 VALID In the context of this document, a DKIM message which 149 has passed all verification test. 151 INVALID In the context of this document, a DKIM signed message 152 which has failed the verification process for one 153 reason or another. 155 TRANSACTION The client/server transfer of an email message. 157 SIGNER A process or agent that adds a DKIM signature to a 158 message. 160 VERIFIER A process or agent that performs the DKIM message 161 verification. 163 2. Introduction 165 This document describes the DKIM Signature Authorization Protocol 166 (DSAP) designed to provide signature authorization controls for the 167 DKIM [DKIM-BASE] (Domain Keys Identified Message) core protocol. 169 The object of DSAP is to provide the following added-value security 170 to DKIM core protocol: 172 o Protect domain DKIM message signing practices, 173 o Protect domain reputations, 174 o Reduce DKIM verification overhead, 175 o Simplify DKIM implementation design considerations, 176 o Help increase DKIM acceptibility, and 177 o Help lower DKIM adoption barriers. 179 DKIM is an electronic mail authentication protocol designed to 180 strengthen the integrity of RFC 2822 [RFC2822] based message objects 181 using a public-key cryptography and key server technology. DKIM 182 permits verification of the source and contents of messages by either 183 Mail Destination Agents (MDAs), Mail Transfer Agents (MTAs) or Mail 184 User Agents (MUAs). 186 The objective of the DKIM framework is to permit a signing domain the 187 ability to protect the message sender identity and the integrity of a 188 message. This process asserts a new reputation accountability for 189 the domain responsible for the message. Ultimately, the goal is to 190 assist in the control of fraud, spam and phishing. 192 Inherently, the DKIM core protocol is modeled around a "good citizen" 193 or valid signature concept and does not attempt to place any meaning 194 behind invalid or unverifable signatures, including how an invalid 195 signature condition was met, leaving message classification to 196 intentionally vague and undefined local policy decisions and as 197 feedback to future augmented mail filtering systems. 199 While this is an a worthy endeavor for the design and purity of a 200 core protocol, this core model and its intentional vague DKIM 201 protocol semantics leads to concerns with the unprotected nature of 202 message signing practice of DKIM implementations exposing the signing 203 domains to exploitation, malicious abuse, and unauthorized usage. 204 There are many engineering concerns with the stand-alone and 205 unprotected usage of the DKIM protocol in a widely adopted network. 207 A standalone DKIM core protocol implementation is unprotected for the 208 following reasons: 210 o No protection against domain name exploitations, 211 o No foundation for consistent DKIM verification, 212 o Increases verification overhead, placing a high burden on 213 verifiers, 214 o Provides little payoff (low efficiency), 215 o Hedges future on unknown, yet to be delivered, trusted-layers 216 protocols (Reputation Services). 218 To increase the acceptability of the DKIM protocol, it needs to offer 219 value to all parties. DSAP adds a simple to implement security layer 220 around the unprotected core DKIM protocol. When DSAP complimented 221 with DKIM, DKIM will have less of a negative impact on domain 222 reputations and verifiers and will make it easier for developers to 223 add DKIM signing support. 225 DSAP does not attempt to evaluate the reputation of the sender or 226 client. A good intention client can use DSAP as well as the bad 227 intention client. The main objective of DSAP is to establish a 228 protocol consistency between all client types and to use the 229 deviation from the consistency as part of a failure detection system. 231 2.1. Background: How did we get here? 233 For a complete functional and technical description of DKIM, please 234 review the protocol specification described in DKIM [DKIM-BASE]. 236 This section will provide a basic overiew of the DKIM protocol, its 237 security and implementation issues. 239 2.1.1. DKIM Protocol Overview 241 The DKIM core protocol allows an domain to take responsibility for a 242 transportation of a message to a remote host receiver system. 243 Although, the domain's reputation is now at stake when signing 244 messages with the DKIM protocol, DKIM does not attempt to prescribe 245 any specific actions for remote host receivers to take upon 246 successful or unsuccessful validation of DKIM signed messages, nor 247 does DKIM make any assertions about the behavior of the identity 248 doing the signing. 250 Overall, the DKIM protocol design is primarily modeled on the basis 251 of a "well behaved" market place. Unfortunately, DKIM has little to 252 no concerns about failure or error analysis leaving the repudiation 253 process to future technology. 255 This makes DKIM an unsafe and unprotected as a standalone protocol. 257 2.1.2. DKIM Security Issues 259 Implementing the DKIM verification protocol specification as 260 described in DKIM [DKIM-BASE] leaves domain signature authorization 261 insecured. This is best shown in the following illustration: 263 DOMAIN USER 264 | 265 V 266 +------------+ +-----------+ +-------------+ 267 | RECEIVER |<-----| TRANSPORT |<-----| DKIM SIGNER | 268 +------------+ +-----------+ +-------------+ 269 | 270 | 271 ------- 272 PAYLOAD 273 ------- 274 | 275 __V____ 276 / \ +------------+ 277 / SIGNED \---NO--------------------->| CONTINUE | 278 \ MESSAGE?/ +------------+ 279 \_______/ 280 | 281 YES 282 | 283 V +--------------+ 284 +-----------+ | CONTINUE/ | 285 | |------------------------>| CLASSIFY | 286 | | INVALID SIGNATURE +--------------+ 287 | DKIM | 288 | SIGNATURE | 289 | VERIFIER | +--------------+ 290 | |------------------------>| PASS | 291 | | VALID SIGNATURE +--------------+ 292 +-----------+ 294 Figure 1: DKIM Verification Outline 296 As illustrated, a domain user submits a message which is signed by 297 the DKIM compliant domain administative unit. The message is then 298 transported to a DKIM compliant receiver where the payload is 299 received and DKIM verification begins. If the message is not signed, 300 the transaction continues in its normal manner. However, if a 301 signature exist and the signatrure is valid, then the message is 302 considered valid for passage. If the signature is not valid, then 303 the process continues as if the signature never existed. 305 Implementing DKIM without some kind of signing authorization concept, 306 opens the door to domain exploitations by not addressing the most 307 obvious signing practices possible, such as: 309 o Does the domain ever distribute mail? 310 o Do you expect the mail to be unsigned? 311 o Do you expect to sign all mail? 312 o Is your domain the exclusive signer? 313 o Are 3rd party signers or signatures allowed? 314 o Are 3rd party signers allowed to strip your original signatures? 316 These are basic fundamental signature authorization considerations 317 that are lacking in the core DKIM protocol message signature 318 methodology. 320 2.1.3. DKIM Implementation Issues 322 There are two sets of DKIM implementation issues which are 323 complicated when there is no signature authorization controls: 325 o Complex DKIM signing methodology, and 326 o Low efficacy DKIM verification process. 328 *Signing Messages* 330 The DKIM signing methodology offers little control over the 331 authorization of the signature process. The presumption is that the 332 sender has authorized to sign mail. Domains have no control over who 333 may sign mail. This is particularily the case when there is 334 involvement of 3rd party signers , such as Mailing List Servers. 336 Most Mailing List Server (MLS) applications have practices of 337 altering the message body content, including altering the message 338 headers. This practice will destroy the integrity of DKIM signed 339 messages lowering the effectiveness of the DKIM protocol. 341 *Signature Verification* 343 The DKIM verification process, as illustrated in Figure 1.0 344 (Figure 1), is modeled using the basic premise: 346 o If not signed, continue. 347 o If signature is not valid, continue if never signed. 349 The only case for reliability is when the DKIM signature is verified. 350 However, even then, this valid signature may be done on a domain 351 which did not authorize this signing process. 353 3. Implementing DSAP 355 The DKIM [DKIM-BASE] protocol has two complimentary components: 357 1. DKIM Signers 358 2. DKIM Verifier 360 Signers add a DKIM signature to messages before and verifiers 361 validate the DKIM signed messages. Valid signatures provide an 362 assertion of proving email authentication. 364 DSAP may be integrated at the DKIM signer by the domain wishing to 365 enhanced its security by exposing its message signing policy or 366 practice, and at the DKIM verifier wishing to be consistent and honor 367 a domain's signature authoration policies. 369 3.1. Verifiers 371 It is higly recommended DKIM implementations also implement DSAP in 372 order to secure the unprotected nature of DKIM only operations. 374 Where exactly DSAP is implementation in a mail framework is out of 375 scope of this protocol. However, in general, DSAP is likely to be 376 implemented at the transport level or the post transaction level. 378 +-----------+ 379 | PAYLOAD | 380 +-----------+ 381 | 382 v 383 +----------------+ 384 | | +------------+ 385 | DKIM |--------------------------->| CONTINUE | 386 | Signature | UNSIGNED: OPTIONAL +------------+ 387 | Authorization | 388 | Protocol | 389 | | +------------+ 390 | |--------------------------->| | 391 | | SIGNED: EXPIRED (1) | | 392 | |--------------------------->| | 393 | | NO MAIL EXPECTED (4) | FAILURE/ | 394 | |--------------------------->| CLASSIFY | 395 | | UNSIGNED: REQUIRED (5) | | 396 | |--------------------------->| | 397 | | SIGNED: NOT EXPECTED (6) | | 398 | |--------------------------->| | 399 | | 3P SIGNED: NOT ALLOWED (7) | | 400 +----------------+ +------------+ 401 | 402 | 403 SIGNED 404 MESSAGE 405 | 406 v +------------+ 407 +--------------+ | CONTINUE/ | 408 | |--------------------------->| CLASSIFY | 409 | | INVALID SIGNATURE +------------+ 410 | DKIM | 411 | SIGNATURE | 412 | VERIFICATION | +------------+ 413 | (8) |--------------------------->| PASS | 414 | | VALID SIGNATURE +------------+ 415 +--------------+ 417 Figure 2: DKIM Signature Authorization Protocol Outline 419 The following steps MUST be followed by the DSAP compliant DKIM 420 verifier once the PAYLOAD headers are available. The sequential 421 steps outlined provide conditions and criteria for negatively 422 classifying a transaction: 424 1. If a signature exist, check to see if the signature has expired 425 (see DKIM [DKIM-BASE] expiration tag). Signatures MUST NOT be 426 considered valid if the current time is past the expiration date. 428 2. Extract the 2822.From: domain and perform a DSAP DNS query as 429 defined in Section 4 to obtain the domain signature authorization 430 policy. 432 3. For NXDOMAIN results and the message is signed, the transaction 433 SHOULD be rejected. A temporary negative response code, such as 434 451, MAY be issued to address any domain DNS configuration 435 delays. 437 4. If the op= and 3p= tags are missing or empty, no mail is expected 438 from this domain. The transaction SHOULD be rejected. 440 5. If the message is not signed, and a signature was expected 441 (op=always or 3p=always), the transaction SHOULD be rejected. 443 6. If the message is signed, and no signature was expected (op=never 444 and 3p=never), the transaction SHOULD be rejected. 446 7. If the message is signed by a 3rd party signer, and a 3rd party 447 signer was not expected (3p=never), the transaction SHOULD be 448 rejected. 450 8. If the message is signed, perform the DKIM verification process 451 as defined in DKIM [DKIM-BASE] section 6.2. 453 3.2. Signers 455 Steps for DKIM signers supporting DSAP: 457 1. Define a DSAP DNS TXT record as described in Section 4. 459 2. Establish an original party and 3rd party signing policy which 460 best suits the domain DKIM signing practice. This includes the 461 following considerations: 463 * Does the domain ever distribute mail? 464 * Do you expect the mail to be unsigned? 465 * Do you expect to sign all mail? 466 * Is your domain the exclusive signer? 467 * Are 3rd party signers allowed? 468 * Are 3rd party signers allowed to strip your original 469 signatures? 471 3. As described in DKIM [DKIM-BASE] Section 3.6, signature 472 applications require some level of assurance that the 473 verification public key is associated with the claimed signer. 474 When signing hosted domain, routed, passthru or mailing list 475 mail, check the originating domain's DSAP 3rd party resigning 476 policy. [[EDITOR-NOTE-MLS-RESIGNERS: Mailing List resigners need 477 extra consideration here. Originating domains should be aware of 478 the risk associated with sending signed mail to a mailing list 479 server.]] 481 4. If allowed to sign, follow DKIM [DKIM-BASE] to sign the message 483 3.3. Mailing List Servers 485 Mailing List Servers (MLS) applications who are compliant with DKIM 486 and DSAP operations, SHOULD adhere to the following guidelines: 488 Subscription Controls 490 MLS subscription processes should perform a DSAP check to 491 determine if a subscribing email domain DSAP policy is restrictive 492 in regards to mail integrity changes or 3rd party signatures. The 493 MLS SHOULD only allow original domain policies who allow 3rd party 494 signatures. 496 Message Content Integrity Change 498 List Servers which will alter the message content SHOULD only do 499 so for original domains with optional DKIM signing practices and 500 it should remove the original signature if present. If the List 501 Server is not going to alter the message, it SHOULD NOT remove the 502 signature, if present. 504 4. DSAP DNS Resource Record 506 DSAP clients MUST perform TXT DNS queries based on domain part of the 507 originating address, RFC2822.From header field, using the following 508 DNS query question format: 510 RR Type = TXT 511 Domain = _dsap._domainkey. 513 Where is the domain part of the originating address. 515 If the domain is DSAP compliant, the resultant TXT record is a string 516 containing semi-colon-delimited tags. The current DSAP policy tags 517 are defined in the following table: 519 +============================================================+ 520 | Description | DSAP Record Tag | 521 |============================================================| 522 | Version tag | v=/ | 523 |------------------------------------------------------------| 524 | Original party signing | op= | 525 | practice | | 526 |------------------------------------------------------------| 527 | 3rd party signing | 3p= | 528 | practice | | 529 |------------------------------------------------------------| 530 | Authorized List of | dl= | 531 | 3rd party domains | | 532 |------------------------------------------------------------| 533 | Signature Hashing | a= | 534 | Method | | 535 |------------------------------------------------------------| 536 | Reporting address | r= | 537 |------------------------------------------------------------| 538 | Note or comment | n= | 539 |------------------------------------------------------------| 540 | Testing flag | t= | 541 |------------------------------------------------------------| 542 | Unauthorized signature | fa= | 543 | failure handling | | 544 |------------------------------------------------------------| 545 | Invalid Signature | fs= | 546 | failure handling | | 547 |------------------------------------------------------------| 548 | Signature Expiration | fx= | 549 | failure handling | | 550 +------------------------------------------------------------+ 552 DSAP DNS Record Poicy Tags 554 4.1. DSAP Tag: v=/ 556 This tag defines the current version number of the DSAP and DKIM 557 implementation. 559 For the current DSAP document draft level production, the values are: 561 v=dsap1.0/dkim1 563 4.2. DSAP Tags: op=; 3p=; 565 From the viewpoint of the verifier, when a message is received, there 566 are two basic pieces of signature information to be of interest when 567 analyzing the transaction: 569 o Original Party Signatures (OP) 571 * never expected 572 * always expected 573 * optional 575 o 3rd Party Signatures (3P) 577 * never expected 578 * always expected 579 * optional 581 When the two signature types are combines, the possible policies are 582 listed in this following table: 584 +=================================================================+ 585 | op= | 3p= | Domain Policy Semantics | 586 |=================================================================| 587 | empty | empty | No mail expected | 588 |-----------------------------------------------------------------| 589 | never | never | No signing expected | 590 | never | always | Only 3P signing expected | 591 | never | optional | Only 3P signing optional | 592 |-----------------------------------------------------------------| 593 | always | never | OP signature expected | 594 | always | always | Both parties expected | 595 | always | optional | OP expected, 3P may sign | 596 |-----------------------------------------------------------------| 597 | optional | never | Only OP signing expected | 598 | optional | always | OP expected, 3P expected | 599 | optional | optional | Both parties may sign. | 600 +-----------------------------------------------------------------+ 602 Figure 4: DSAP Message Signing Policies 604 The goal here is to establish what the domain signature policy is and 605 whether the domain allows 3rd party entities to resign the message 606 independently or on behalf of original domain. 608 Domains should define op= and 3p= policies which best defines their 609 mail operations to best secure their mail transactions. The policies 610 are described in detail in Section 5. 612 4.3. DSAP Tag; 3pl=; 614 The 3pl= is an optional tag that defines a list of 3rd party domains 615 who are allowed to DKIM sign the message as a 3rd party signer. This 616 tag is ignored unless 3rd party signing policy is expected or 617 optional (3p=always or 3p=optional). 619 is a comma delimited list of domain names. 621 Example: 623 3pl=isp.com,outsource.com,mailinglist.com; 625 4.4. DSAP Tag: a= 627 The a= tag defines the possible signature hashing 628 algorithms used by the domain DKIM message signer. The a= tag is NOT 629 optional. 631 The current algorithms are defined in DKIM [DKIM-BASE] section 3.3. 633 o rsa-sha1 634 o rsa-sha256 636 Example: 638 a=rsa-sha1,rsa-sha256; 640 The main purpose of the a= tag is to allow domain signers the design 641 and implementation opportunity to determine the highest strength 642 possible by a particular target verifier by looking the DSAP DNS 643 record for the target recipient domain host. If this query results 644 with no a= tag information, the default should be rsa-sha1 is the 645 highest strength possible. 647 Essentially, this is a negotiation and backward compatibility 648 concept. It is quite possible earlier pre-standard DKIM 649 implementations supporting only rsa-sha1 may still exist. The domain 650 DKIM message signer's desire is to achieve the highest protection 651 possible. Instead of signing mail with a particular algorithm and 652 hoping for the best, the signer can predetermine what the receiving 653 system can handle in terms of hashing strength. 655 [[anchor17: This verifier lookup concept is best utilize for high- 656 value domains in 1 to 1 transactions. It would not be practice 657 Mailing List resigners with large distributions to use this 658 concept.]] 660 4.5. DSAP Tag: r= 662 This tag is optional. If not defined, the default is no abuse- 663 address is available. 665 is either the user-part or a FQDN email address to 666 optional send abuse reports. 668 Examples: 669 r=abuse 670 r=abuse@example.com 672 If only the user-part is defined, then the full address is 673 established by using the originating address domain. 675 DKIM verifiers have the option to honor or not honor this reporting 676 address. DKIM signers MUST be aware this reporting address may not 677 be utilized by verifers. 679 Verifiers should be aware this reporting address can be a source of 680 an report attack vector (Section 7.4). One possible implementation 681 considerations would to limit the report to one report only and to 682 track the reception and/or response of the reporting. 684 4.6. DSAP Tag: n= 686 The note tag (n=) is optional. It allows a domain to store a human 687 readable note or comment regarding the DSAP DNS record. Its purpose 688 is considered to be diagnostic in nature. 690 4.7. DSAP Tag: t=y 692 The t=y tag is optional. If defined, the domain is currently testing 693 DKIM. Verifiers SHOULD NOT treat testers any different from 694 production mode signers. It SHOULD NOT be used as a way to bypass a 695 failed signature classification policies. However, verifiers SHOULD 696 track testers for over extended usage of test signatures and MAY 697 consider using the results to provide feedback to the domain. 699 4.8. DSAP Tags: fa=; fs=; 700 fx=; 702 The fa=, fs, and fx= tags define the domain preferred rejection 703 action policy a verifier is recommended to perform when an 704 unauthorized signature, failed signature or expired signature is 705 detected, respectively. 707 The fa= tag defines the handling for failed signature authorization. 709 The fs= tag defines the handling for failed signature verfication, 710 and the fx= tag defines the handling when a signature expired or key 711 is revoked. 713 Failed signature include failures related to the DKIM-Signature 714 hashing, syntax and encryption verification process. 716 values: 718 FAIL The verifer MUST reject the transaction when 719 failure is detected. (Default) 721 SOFTFAIL The verifer SHOULD reject the transaction when 722 failure is detected. 724 IGNORE The verifer SHOULD NOT reject the transaction 725 when failure is detected. This value may be 726 defined by the domain to signify the domain is 727 testing DKIM and failure may occur unexpectedly. 728 Verifiers SHOULD consider tracking this handler 729 value for abuse. 731 The fa= and fs= tags are optional with default values of SOFTFAIL. 733 Examples: 735 fa=fail;fs=fail; fx=fail; Domain has a MUST reject immediate policy 736 for unauthorized, failed or expired signatures. 738 fa=fail; Domain has a MUST reject immediate policy for 739 unauthorized signatures and a SHOULD reject 740 immediate policy for failed and expired 741 signatures. 743 undefined tags; DOMAIN has a SHOULD reject immediate policy for 744 all failures. 746 fs=fail; fx=fail; Domain has a SHOULD reject immediate policy for 747 unauthorized signatures and a MUST reject 748 immediate policy for failed and expired 749 signatures. 751 4.9. Symbolic Semantics 753 There might be DNS capacity overhead concern with the expanded 754 literal representation for the policies and fail handling tags. To 755 help address this, the following alias characters can be used for the 756 literal values: 758 o op= and 3p= signing policy values 760 always (+) 761 never (-) 762 optional (~) 764 o fa=, fs=, and fx= failure-handling values 766 fail (+) 767 softfail (~) 768 ignore (-) 770 5. DSAP Policies 772 Domains should define a DSAP policy which best describes their mail 773 operations for DKIM signatures. The following subsections list 774 possible values and explain their use: 776 5.1. No Mail Expected 778 *Policy: op=; 3p=;* 780 If this policy is defined, then no mail is expected from the original 781 domain. It is intent of the responsiible domain to not allow email 782 domain to be use for any kind for mail transactions. Verifiers 783 SHOULD honor this domain policy request to negatively classify the 784 message. 786 Here is an example of a domain DNS TXT record No Mail Policy: 788 _dsap._domainkey.example.com. IN TXT 789 "v=dsap1.0; op=; 3p=; fa=fail; 790 n=We never send mail from this domain. 791 r=dkim-abuse@example.com;" 793 5.2. No Signature Expected 795 *Policy: op=never; 3p=never;* 797 If this policy is defined, then a DKIM signature is not expected from 798 any party. If a DKIM signature is found in the message, verify or 799 not, the verifier SHOULD honor the domain request to negatively 800 classify the message. 802 Here is an example of a domain DNS TXT record Never Sign Policy: 804 _dsap._domainkey.example.com. IN TXT 805 "v=dsap1.0; op=never; 3p=never; fa=fail; 806 n=We never sign messages, nor should anyone else. 807 r=dkim-abuse@example.com;" 809 5.3. Only 3rd party Signature Expected 811 *Policy: op=never; 3p=always;* 813 If this policy is defined, then a DKIM signature MUST exist and it 814 must be signed by a 3rd party. If a DKIM signature is not found in 815 the message, or an original party signature is found, the verifier 816 SHOULD honor the domain policy request to negatively classify the 817 message. This policy maybe used in situations where domain owner 818 never sends any email directly and always employs 3rd parties to send 819 on its behalf and its known that all 3rd parties used are known to be 820 sign messages. 822 Here is an example of a domain DNS TXT record for this 3rd party only 823 signing policy: 825 _dsap._domainkey.example.com. IN TXT 826 "v=dsap1.0; op=never; 3p=always; fa=fail; fx=fail; 827 n=We never sign messages, nor should anyone else. 828 r=dkim-abuse@example.com;" 830 5.4. Only 3rd party Signature Expected, if any 832 *Policy: op=never; 3p=optional;* 834 If this policy is defined, then a DKIM signature MAY exist and it 835 must be signed by a 3rd party . If an original partry DKIM signature 836 is found, verify or not, the verifier SHOULD honor the domain request 837 to negatively classify the message. 839 5.5. Only Original Party Signature Expected 841 *Policy: op=always; 3p=never;* 843 If this policy is defined, then a DKIM signature MUST exist and it 844 must be signed by the original domain only. If no signature is found 845 or a 3rd party signature is found, the verifier SHOULD honor the 846 domain policy request to negatively classify the message. 848 This policy is considered to be an exclusive signing practice by the 849 original domain only and is expected to be used by organizations that 850 never send any email to mail lists or through 3rd parties and always 851 expect to communicate directly with recipient. Such organizations 852 are those providing data of very sensitive nature (such as personal 853 financial information) and using strong internal security policies. 854 These organizations are often highly concerned about inappropriate 855 and fraudulent uses of their domain (such as cases of "phishing") and 856 want to make sure that only emails directly from their system are 857 accepted as valid by recipient. 859 Here is an example of such policy record used by an imaginary Bank 860 with domain bank.example. Please note tags are separate per line for 861 illustrative purposes only: 863 _dsap._domainkey.bank.example. IN TXT 864 "v=dsap1.0; a=rsa-sha256; op=always; 3p=never; 865 n=We only send DKIM signed email, do not trust anything else 866 such as notices allegedly from security@bank.example. Please 867 report all such abuse to; 868 r=phishing-reports@bank.example;" 870 Note: The above comment in "n" tag is very long and given only to 871 help illustrate this example. Whenever possible shorter text should 872 be used in DSAP records. 874 5.6. Original and 3rd party Signatures Expected 876 *Policy: op=always; 3p=always; * 878 If this policy is defined, then two or more DKIM signatures 879 signatures are expected to exist in the message. The first one is 880 the original party signature, and the subsequent signatues are 3rd 881 party signatures. If no signatures are found or either the original 882 or 3rd party signatures are missing, verify or not, the verifier 883 SHOULD honor the domain request to negatively classify the message. 885 5.7. Original Party Signature Expected, 3rd party Optional 887 *Policy: op=always; 3p=optional; * 889 If this policy is defined, then one or more DKIM signatures 890 signatures are expected to exist in the message. The first one is a 891 required original party signature, and any subsequent signatures are 892 3rd party signatures. If no signatures are found or the original 893 party signature does not exist, verify or not, the verifier SHOULD 894 honor the domain policy request to negatively classify the message. 896 5.8. Only Original Party Signature Expected, if any 898 *Policy: op=optional; 3p=never; * 900 If this policy is defined, then only an original party DKIM signature 901 may exist. If a 3rd party signature is found, verify or not, the 902 verifier SHOULD honor the domain policy request to negatively 903 classify the message. 905 Mailing List Servers MAY strip the signature from the message for 906 list distribution. 908 [[anchor31: The idea is if a domain optional signs a messages for a 909 mailing list submission, should the LS be allowed to removed. If the 910 OA signature was required. the LS should not remove it. However, if 911 a optional policy is used, then veriifers will survive any LS mail 912 integrity changes as long as the OA signature is removed.]] 914 5.9. Original Party Optional, 3rd Party Signature Expected 916 *Policy: op=optional; 3p=always;* 918 If this policy is defined, then one or more DKIM signatures 919 signatures are expected to exist in the message. The first one is 920 the original party signature and it is optional. Only the 3rd party 921 signature is expected to exist. If no signatures are found or the 922 3rd party signature is missing, verify or not, the verifier SHOULD 923 honor the domain request to negatively classify the message. 925 Since List Servers must sign the message, it SHOULD strip the 926 original party signature from the message for list distribution if 927 the mail integrity has changed. 929 [[anchor33: Why would a domain use this 3PS must sign policy?]] 931 5.10. Optional Original Party or 3rd Party Signatures 933 *Policy: op=optional; 3p=optional;* 935 If this policy is defined, then one or more DKIM signatures 936 signatures may exist in the message. The original or 3rd party 937 signatures are optional. The first one is the original party 938 signature, and any subsequent signatures are 3rd party signatures. 939 If no signatures are found, the verifier SHOULD honor the domain 940 request to positively classify the message. 942 List Servers MAY strip the original party signature from the message 943 for list distribution. 945 6. IANA Considerations 947 This document makes no request of IANA. 949 Note to RFC Editor: this section may be removed on publication as an 950 RFC. 952 7. Security Considerations 954 7.1. Policy Attacks 956 Policy attacks are those when a bad actor is sending mail using an 957 originating address that is highly restrictive with the sole purpose 958 to stop the delivery of mail. 960 7.2. Multiple Original Addresses 962 TBD 964 7.3. Denial-of-Service Attacks 966 TBD 968 7.4. Abuse Report Address Attacks 970 TBD 972 8. Acknowledgements 974 Discussions related to siganture policies in the IETF-DKIM Working 975 Group among many participants lead to the development of this 976 proposed draft. There are a few contributors who wish to remain 977 anonymous who provided rich guidance and editorial input. Mr. Santos 978 extends his appreciation for their contributions to the proposal. 980 9. References 982 9.1. Normative References 984 [DKIM-BASE] 985 Allman, E., "DomainKeys Identified Mail Signatures", 986 April 2006, . 989 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 990 Requirement Levels", BCP 14, RFC 2119, March 1997. 992 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 993 April 2001. 995 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 996 April 2001. 998 9.2. Informative References 1000 Appendix A. DKIM-BASE Update Considerations 1002 In an effort to offer upward compatibility for current DKIM BASE 1003 implementation who may wish to expose their desire to support DSAP, 1004 the following key record TXT tag is defined: 1006 dsap=1; 1008 If this tag is defined in the _domainkey. TXT record, the 1009 verifier SHOULD consider honoring the domain's desire to better 1010 secure its DKIM mail signing practice. 1012 SInce DKIM-BASE only implementations will lookup the key record 1013 first, the inclusion of the dsap=1 tag could server as a tracked or 1014 traced item during verification. Verifiers would then be able to 1015 review their implementation for enhancing domain DKIM signature 1016 authorization security by incorporating DSAP. 1018 Author's Address 1020 Hector Santos 1021 Santronics Software, Inc. 1022 15600 SW 158 ST Suite #306 1023 Homestead, Florida, FL 33033 1024 United States of America 1026 Email: hsantos@isdg.net 1027 URI: http://www.isdg.net 1029 Full Copyright Statement 1031 Copyright (C) The Internet Society (2006). 1033 This document is subject to the rights, licenses and restrictions 1034 contained in BCP 78, and except as set forth therein, the authors 1035 retain all their rights. 1037 This document and the information contained herein are provided on an 1038 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1039 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1040 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1041 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1042 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1043 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1045 Intellectual Property 1047 The IETF takes no position regarding the validity or scope of any 1048 Intellectual Property Rights or other rights that might be claimed to 1049 pertain to the implementation or use of the technology described in 1050 this document or the extent to which any license under such rights 1051 might or might not be available; nor does it represent that it has 1052 made any independent effort to identify any such rights. Information 1053 on the procedures with respect to rights in RFC documents can be 1054 found in BCP 78 and BCP 79. 1056 Copies of IPR disclosures made to the IETF Secretariat and any 1057 assurances of licenses to be made available, or the result of an 1058 attempt made to obtain a general license or permission for the use of 1059 such proprietary rights by implementers or users of this 1060 specification can be obtained from the IETF on-line IPR repository at 1061 http://www.ietf.org/ipr. 1063 The IETF invites any interested party to bring to its attention any 1064 copyrights, patents or patent applications, or other proprietary 1065 rights that may cover technology that may be required to implement 1066 this standard. Please address the information to the IETF at 1067 ietf-ipr@ietf.org. 1069 Acknowledgment 1071 Funding for the RFC Editor function is provided by the IETF 1072 Administrative Support Activity (IASA).