idnits 2.17.1 draft-ietf-dkim-deployment-02.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1013. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1024. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1031. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1037. 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 590: '... o The verifier MAY change the degree...' RFC 2119 keyword, line 595: '... * A verifier MAY evaluate signatur...' RFC 2119 keyword, line 599: '... o The verifier MAY make a determinat...' RFC 2119 keyword, line 607: '... o The verifier MAY decide to add sup...' RFC 2119 keyword, line 610: '... * The verifier MAY add support for a...' (6 more instances...) 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 (November 3, 2008) is 5646 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-openpgp-rfc2440bis' is defined on line 914, but no explicit reference was found in the text == Unused Reference: 'RFC0989' is defined on line 925, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 929, but no explicit reference was found in the text == Unused Reference: 'RFC1848' is defined on line 932, but no explicit reference was found in the text == Unused Reference: 'RFC1991' is defined on line 935, but no explicit reference was found in the text == Unused Reference: 'RFC2440' is defined on line 938, but no explicit reference was found in the text == Unused Reference: 'RFC2821' is defined on line 941, but no explicit reference was found in the text == Unused Reference: 'RFC2822' is defined on line 944, but no explicit reference was found in the text == Unused Reference: 'RFC3156' is defined on line 947, but no explicit reference was found in the text == Unused Reference: 'RFC3164' is defined on line 950, but no explicit reference was found in the text == Unused Reference: 'RFC3851' is defined on line 953, but no explicit reference was found in the text == Unused Reference: 'RFC4686' is defined on line 957, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-kucherawy-sender-auth-header-17 -- Obsolete informational reference (is this intentional?): RFC 989 (Obsoleted by RFC 1040, RFC 1113) -- Obsolete informational reference (is this intentional?): RFC 1991 (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 2440 (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 3164 (Obsoleted by RFC 5424) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 4870 (Obsoleted by RFC 4871) -- Obsolete informational reference (is this intentional?): RFC 4871 (Obsoleted by RFC 6376) Summary: 3 errors (**), 0 flaws (~~), 14 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DomainKeys Identified Mail T. Hansen 3 Internet-Draft AT&T Laboratories 4 Intended status: Informational P. Hallam-Baker 5 Expires: May 7, 2009 VeriSign Inc. 6 D. Crocker 7 Brandenburg InternetWorking 8 E. Siegel 9 Constant Contact, Inc. 10 November 3, 2008 12 DomainKeys Identified Mail (DKIM) Development, Deployment and Operations 13 draft-ietf-dkim-deployment-02 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 7, 2009. 40 Abstract 42 DomainKeys Identified Mail (DKIM) allows an organization to take 43 responsibility for transmitting a message, in a way that can be 44 validated by a recipient. The organization can be the author's, the 45 originating sending site, an intermediary, or one of their agents. A 46 message can contain multiple signatures, from the same or different 47 organizations involved with the message. DKIM defines a domain-level 48 digital signature authentication framework for email, using public 49 key cryptography, using the domain name service as its key server 50 technology [RFC4871]. This permits verification of a responsible 51 organization, as well as the integrity of the message contents. DKIM 52 will also provide a mechanism that permits potential email signers to 53 publish information about their email signing practices; this will 54 permit email receivers to make additional assessments about messages. 55 DKIM's authentication of email identity can assist in the global 56 control of "spam" and "phishing. This document provides 57 implementation, deployment, operational and migration considerations 58 for DKIM. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Key Generation, Storage, and Management . . . . . . . . . . . 3 64 2.1. General Coding Criteria for Cryptographic Applications . . 3 65 2.2. Key Generation and Storage . . . . . . . . . . . . . . . . 4 66 2.3. DNS Signature Record Deployment and Maintenance 67 Considerations . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.1. Deployment . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.2. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 10 71 3.3. Signature Transition Strategy . . . . . . . . . . . . . . 12 72 4. Verifying . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 4.1. Verifier . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 4.2. DNS Client . . . . . . . . . . . . . . . . . . . . . . . . 14 75 4.3. Boundary Enforcement . . . . . . . . . . . . . . . . . . . 15 76 4.4. Filtering Software . . . . . . . . . . . . . . . . . . . . 15 77 5. DKIM Deployment Considerations for Email Agents . . . . . . . 15 78 5.1. Email Infrastructure Agents . . . . . . . . . . . . . . . 15 79 5.2. Mail User Agent . . . . . . . . . . . . . . . . . . . . . 17 80 6. Migrating from DomainKeys . . . . . . . . . . . . . . . . . . 17 81 6.1. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 6.2. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 18 83 7. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 7.1. Protection of Internal Mail . . . . . . . . . . . . . . . 18 85 7.2. Recipient-based Assessments . . . . . . . . . . . . . . . 19 86 7.3. DKIM Support in the Client . . . . . . . . . . . . . . . . 19 87 7.4. Per user signatures . . . . . . . . . . . . . . . . . . . 19 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 91 11. Informative References . . . . . . . . . . . . . . . . . . . . 20 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 93 Intellectual Property and Copyright Statements . . . . . . . . . . 23 95 1. Introduction 97 There are many areas to be considered when deploying DomainKeys 98 Identified Mail (DKIM). This document provides practical tips for: 99 those who are developing DKIM software, mailing list managers, 100 filtering strategies based on the output from DKIM verification, and 101 DNS servers; those who are deploying DKIM software, keys, mailing 102 list software, and migrating from DomainKeys; and those who are 103 responsible for the on-going operations of an email infrastructure 104 that has deployed DKIM. 106 The document is organized aorund the key concepts related to DKIM. 107 Within each section, additional considerations specific to 108 development, deployment, or ongoing operations are highlighted where 109 appropriate. 111 [[anchor2: maybe this is a good place to mention the possibility of 112 collecting verification history for selectors domains as a means of 113 observing over time behaviour of signers for the purpose of asserting 114 local reputation]] 116 2. Key Generation, Storage, and Management 118 DKIM defines a domain-level digital signature authentication 119 framework for email, using public key cryptography, using the domain 120 name service as its key server technology [RFC4871]. This section 121 covers considerations around generating, deploying, and managing the 122 public and private keys required for DKIM to function. 124 2.1. General Coding Criteria for Cryptographic Applications 126 NOTE: This section could possibly be changed into a reference to 127 something else, such as another rfc. 129 Correct implementation of a cryptographic algorithm is a necessary 130 but not a sufficient condition for the coding of cryptographic 131 applications. Coding of cryptographic libraries requires close 132 attention to security considerations that are unique to cryptographic 133 applications. 135 In addition to the usual security coding considerations, such as 136 avoiding buffer or integer overflow and underflow, implementers 137 should pay close attention to management of cryptographic private 138 keys and session keys, ensuring that these are correctly initialized 139 and disposed of. 141 Operating system mechanisms that permit the confidentiality of 142 private keys to be protected against other processes should be used 143 when available. In particular, great care must be taken when 144 releasing memory pages to the operating system to ensure that private 145 key information is not disclosed to other processes. 147 Certain implementations of public key algorithms such as RSA may be 148 vulnerable to a timing analysis attack. 150 Support for cryptographic hardware providing key management 151 capabilities is strongly encouraged. In addition to offering 152 performance benefits, many cryptographic hardware devices provide 153 robust and verifiable management of private keys. 155 Fortunately appropriately designed and coded cryptographic libraries 156 are available for most operating system platforms under license terms 157 compatible with commercial, open source and free software license 158 terms. Use of standard cryptographic libraries is strongly 159 encouraged. These have been extensively tested, reduce development 160 time and support a wide range of cryptographic hardware. 162 2.2. Key Generation and Storage 164 2.2.1. Assignment of Selectors 166 Selectors Selectors are assigned according to the administrative 167 needs of the signing domain, such as for rolling over to a new key 168 or for delegating of the right to authenticate a portion of the 169 namespace to a trusted third party. 171 Examples include: jun2005.eng._domainkey.example.com 173 widget.promotion._domainkey.example.com 175 NOTE: It is intended that assessments of DKIM identities be based 176 on the domain name, and not include the selector. This permits 177 the selector to be used only for key administration, rather than 178 having an effect on reputation assessment. 180 [[anchor7: The reputation of a selector could become relevant if 181 it is known to have "gone rogue" before the DNS owner has a chance 182 to published a new zone update which contains a revoked key.]] 184 2.2.2. Third Party Key Management 186 ???????????????? 188 [[anchor9: what are we trying to cover here? The case where a 3rd 189 party generates keys and provides the public key to the domain owner 190 to publish? Or the case where the domain owner generates keys and 191 provides the private key to the third party? Either way, I think we 192 need some discussion of 1st vs. 3rd party (preferably that the 193 distinction has little relevance except in the presence of ADSP, 194 since otherwise the reputation of the signing domain and not the 1st 195 or 3rd party nature of it is what is relevant.]] 197 3rd party generates the public / private key pair and sends the 198 public key to be published in the DNS. 200 2.2.3. Storing Public Keys: DNS Server Software Considerations 202 At a minimum, a DNS server that handles queries for DKIM key records 203 must allow the server administrators to add free-form TXT records. 204 It would be better if the the DKIM records could be entered using a 205 structured form, supporting the DKIM-specific fields. 207 2.2.4. Private Key Management: Deployment and Ongoing Operations 209 The permissions of private key files must be carefully managed. If 210 key management hardware support is available, it should be used. 211 Auditing software should be used periodically to verify that the 212 permissions on the private key files remain secure. 214 2.3. DNS Signature Record Deployment and Maintenance Considerations 216 Even with use of the DNS, one challenge is that DNS record management 217 is usually operated by an administrative staff that is different from 218 those who operate an organization's email service. In order to 219 ensure that DKIM DNS records are accurate, this imposes a requirement 220 for careful coordination between the two operations groups. 222 The key point to remember is that the DNS DKIM selectors WILL and 223 should be changed over time. Some reasons for changing DKIM 224 selectors are well understood, while others are still theoretical. 225 There are several schemes that may be used to determine the policies 226 for changing DKIM selectors: 228 o time based 230 o associations with clusters of servers 231 o the use of third party signers 233 o security considerations 235 A potential mistake in creating the DNS key record is the erroneous 236 use of a backslash (\) in the definition. Some implementations 237 reading a zone file allow a backslash to be used anywhere, stripping 238 any such occurrences. Other implementations only allow it to be used 239 in front of an quotation mark, storing the backslash in the record 240 and causing a syntax error to be generated by DKIM implementations 241 reading the record. 243 2.3.1. Time Basis and Security Considerations 245 The reason for changing the selector periodically is usually related 246 to the security exposure of a system. When the potential exposure of 247 the private keys associated with the DKIM selector have reached 248 sufficient levels, the selector should be changed. (It is unclear 249 currently what kinds of metrics can be used to aid in deciding when 250 the exposure has reached sufficient levels to warrant changing the 251 selector.) 253 For example, 255 o Selectors should be changed more frequently on systems that are 256 widely exposed, than on systems that are less widely exposed. For 257 example, a gateway system that has numerous externally-accessible 258 services running on it is more widely exposed than one that ONLY 259 runs a mail server. 261 o Selectors should be changed more frequently on operating systems 262 that are under wide attack. 264 o While the use of DKIM information is transient, keys with 265 sufficient exposure do become stale and should be changed. 267 o Whenever you make a substantial system change, such as bringing up 268 a new server, or making a major operating system change, you 269 should consider changing the selector. 271 [[anchor14: above you refer to changing the key, here you refer to 272 changing the selector; they have not been explicitly declared as 273 synonymous so this could be confusing]] 275 o Whenever there is either suspicion or evidence of the compromise 276 of the system or the private keys, you should change the selector. 278 2.3.2. Deploying New Selectors 280 A primary consideration in changing the selector is remembering to 281 change it. It needs to be a standard part of the operational staff 282 Methods and Procedures for your systems. If they are separate, both 283 the mail team and the DNS team will be involved in deploying new 284 selectors. 286 When deploying a new selector, it needs to be phased in: 288 1. Generate the new public / private key pair and create a new 289 selector record with the public key in it. 291 2. Add the new selector record to your DNS. 293 3. Verify that the new selector record can be used to verify 294 signatures. 296 4. Turn on signing with the new private key. 298 5. Remove the old private key from your servers. 300 6. After a period of time, remove the old selector from your DNS. 302 The time an unused selector should be kept in the DNS system is 303 dependent on the reason it's being changed. If the private key has 304 definitely been exposed, the corresponding selector should be removed 305 immediately. Otherwise, longer periods are allowable. 307 [[anchor16: interesting; should we have included a "u=" ('until') tag 308 on key records allowing an advertised "good until" timestamp?]] 310 2.3.3. Subdomain Considerations 312 A Domain Name is the basis for making differential quality 313 assessments about a DKIM-signed message. It is reasonable for a 314 single organization to have a variety of very different activities, 315 which warrant a variety of very different assessments. A convenient 316 way to distinguish among such activities is to sign with different 317 domain names. That is, the organization should sign with sub-domain 318 names that are used for different organizational activities. 320 2.3.4. Delegating Signing Authority to a Third party 322 Allowing third parties to sign email from your domain opens your 323 system security to include the security of the third party's systems. 324 At a minimum, you should not allow the third parties to use the same 325 selector and private key as your main mail system. It is recommended 326 that each third party be given its own private key and selector. 327 This limits the exposure for any given private key, and minimizes the 328 impact if any given private key were exposed. 330 3. Signing 332 3.1. Deployment 334 Creating messages that have DKIM signatures requires a modification 335 to only two portions of the email service: 337 o Addition of relevant DNS information. 339 o Addition of the signature by a trusted module within the 340 organization's email handling service. 342 The signing module uses the appropriate private key to create a 343 signature. The means by which the signing module obtains the private 344 key is not specified by DKIM. Given that DKIM is intended for use 345 during email transit, rather than for long-term storage, it is 346 expected that keys will be changed regularly. Clearly this means 347 that key information should not be hard-coded into software. 349 3.1.1. DNS Records 351 A receiver attempting to verify a DKIM signature must obtain the 352 public key that is associated with the signature for that message. 353 The DKIM-Signature header in the message will specify the basic 354 domain name doing the signing and the selector to be used for the 355 specific public key. Hence, the relevant 356 ._domainkey. DNS record needs to contain a 357 DKIM-related resource record (RR) that provides the public key 358 information. 360 The administrator of the zone containing the relevant domain name 361 adds this information. Initial DKIM DNS information is contained 362 within TXT RRs. DNS administrative software varies considerably in 363 its abilities to add new types of DNS records. 365 3.1.2. Signing Module 367 The module doing signing can be placed anywhere within an 368 organization's trusted Administrative Management Domain (ADMD); 369 common choices are expected to be department-level posting and 370 delivering agents, as well as boundary MTAs to the open Internet. 371 (Note that it is entirely acceptable for MUAs to perform signing and 372 verification.) Hence the choice among the modules depends upon 373 software development and administrative overhead tradeoffs. 375 [[anchor23: See earlier note about signing by MUAs being a security 376 concern]] One perspective that helps resolve this choice is the 377 difference between the flexibility of use by systems at (or close to) 378 the MUA, versus the centralized control that is more easily obtained 379 by implementing the mechanism "deeper" into the organization's email 380 infrastructure, such as at its boundary MTA. 382 3.1.3. DKIM Signing Software Development 384 Signer implementations should provide a convenient means of 385 generating DNS key records corresponding to the signer configuration. 386 Support for automatic insertion of key records into the DNS is also 387 highly desirable. If supported however, such mechanism(s) must be 388 properly authenticated. 390 A means of verifying that the signer configuration is compatible with 391 the signature policy is also highly desirable. 393 Disclosure of a private signature key component to a third party 394 allows that third party to impersonate the sender. The protection of 395 private signature key data is therefore a critical concern. Signers 396 should support use of cryptographic hardware providing key management 397 features. 399 3.1.3.1. Signer Actions 401 All Signers should: 403 o Include any existing Sender header field in the signed header 404 field list, if the Sender header field exists. 406 o ... 408 Signers wishing to avoid the use of Third-Party Signatures should do 409 everything listed above, and also: 411 o Include the Sender header field name in the header field list 412 ("h=" tag) under all circumstances, even if the Sender header 413 field does not exist in the header block. This prevents another 414 entity from adding a Sender header field. 416 o Publish Signing Practices that do not sanction the use of Third- 417 Party Signatures. 419 3.1.4. Signing Policies and Practices 421 Every organization (ADMD) will have its own policies and practices 422 for deciding when to sign messages and with what domain name and key 423 (selector). Examples include signing all mail, signing mail from 424 particular email addresses, or signing mail from particular sub- 425 domains. Given this variability, and the likelihood that signing 426 practices will change over time, it will be useful to have these 427 decisions represented in some sort of configuration information, 428 rather than being more deeply coded into the signing software. 430 3.2. Mailing Lists 432 A mailing list often provides facilities to its administrator to 433 manipulate parts of the mail messages that flow through the list. 434 The desired goal is that messages flowing through the mailing list 435 will be verifiable by the recipient as being from the list, or 436 failing that, as being from the individual list members. 438 There are several forms of mailing lists, which interact with signing 439 in different ways. 441 o "Verbatim" mailing lists send messages without modification 442 whatsoever. They are often implemented as MTA-based aliases. 443 Since they do not modify the message, signatures are unaffected 444 and will continue to verify. It is not necessary for the 445 forwarder to re-sign the message; however, some may choose to do 446 so in order to certify that the message was sent through the list. 448 o "Digesting" mailing lists collect together one or more postings 449 and then retransmit them, often on a nightly basis, to the 450 subscription list. These are essentially entirely new messages 451 which must be independently authored (that is, they will have a 452 "From" header field referring to the list, not the submitters) and 453 signed by the Mailing List Manager itself, if they are signed at 454 all. 456 o "Resending" mailing lists receive a message, modify it (often to 457 add "unsubscribe" information or advertising), and immediately 458 resend that message to the subscription list. They are 459 problematic because they usually do not change the "From" header 460 field of the message, but they do invalidate the signature in the 461 process of modifying the message. 463 In most cases, the list and/or its mail host should add its own DKIM 464 signature to list mail. This could be done in the list management 465 software, in an outgoing MSA or MTA, or both. List management 466 software often makes modifications to messages that will break 467 incoming signatures, such as adding subject tags, adding message 468 headers or footers, and adding, deleting, or reordering MIME parts. 469 By adding its own signature after these modifications, the list 470 provides a verifiable, recognizable signature for list recipients. 472 In some cases, the modifications made by the mailing list software 473 are simple enough that signatures on incoming messages will still be 474 verifiable after being remailed by the list. It is still preferable 475 that the list sign its mail so that recipients can distinguish 476 between mail sent through the list and mail sent directly to a list 477 member. In the absence of a list signature, a recipient may still be 478 able to recognize and use the original signatures of the list 479 members. 481 The first two cases act in obvious ways and do not require further 482 discussion. The remainder of this session applies only to the third 483 case. 485 3.2.1. Mailing List Manager Actions 487 Mailing List Managers should make every effort to ensure that 488 messages that they relay and which have Valid Signatures upon receipt 489 also have Valid Signatures upon retransmission. In particular, 490 Mailing List Managers that modify the message in ways that break 491 existing signatures should: 493 o Verify any existing DKIM Signatures. A DKIM-aware Mailing List 494 Manager must NOT re-sign an improperly signed message in such a 495 way that would imply that the existing signature is acceptable. 497 o Apply regular anti-spam policies. A Mailing List Manager should 498 apply message content security policy just as would be done to 499 messages destined for an individual user's mailbox. In fact, a 500 Mailing List Manager might apply a higher standard to messages 501 destined to a mailing list than would normally be applied to 502 individual messages. 503 NON-NORMATIVE RATIONALE: Since reputation will accrue to signers, 504 Mailing List Managers should verify the source and content of 505 messages before they are willing to sign lest their reputation be 506 sullied by nefarious parties. 508 o Add a Sender header field using a valid address pointing back to 509 the Mailing List Administrator or an appropriate agent (such as an 510 "owner-" or a "-request" address). 512 o Sign the resulting message with a signature that is valid for the 513 Sender header field address. The Mailing List Manager should NOT 514 sign messages for which they are unwilling to accept 515 responsibility. 517 Mailing List Managers MAY: 519 o Reject messages with signatures that do not verify or are 520 otherwise Suspicious. 522 [[anchor29: Is "Suspicious" still a formal term in DKIM?]] 524 3.3. Signature Transition Strategy 526 [[anchor31: I'm not entirely clear what is meant by "algorithm" 527 beyond the combination of key, selector, and signing parameters 528 included in the DKIMSignature header. Unless I'm way off base, I 529 think this section belongs either here under "Signing", or in section 530 1 under "Key Generation, Storage, and Management". Either way, we 531 should be more clear about what is meant by the term "signature 532 algorithm".]] 534 Deployment of a new signature algorithm without a 'flag day' requires 535 a transition strategy such that signers and verifiers can phase in 536 support for the new algorithm independently, and (if necessary) phase 537 out support for the old algorithm independently. 539 [Note: this section assumes that a security policy mechanism exists. 540 It is subject to change.] 542 [[anchor32: safe to presume ADSP?]] 544 DKIM achieves these requirements through two features: First, a 545 signed message may contain multiple signatures created by the same 546 signer. Second, the security policy layer allows the signing 547 algorithms in use to be advertised, thus preventing a downgrade 548 attack. 550 3.3.1. Signer transition strategy 552 Let the old signing algorithm be A and the new signing algorithm be 553 B. The sequence of events by which a Signer may introduce the new 554 signing algorithm B, without disruption of service to legacy 555 verifiers, is as follows: 557 1. Signer signs with algorithm A 559 A. Signer advertises that it signs with algorithm A 561 2. Signer signs messages twice, with both algorithm A and algorithm 562 B 564 A. The signer tests new signing configuration 566 B. Signer advertises that it signs with either algorithm A or 567 algorithm B 569 3. Signer determines that support for Algorithm A is no longer 570 necessary 572 4. Signer determines that support for algorithm A is to be withdrawn 574 A. Signer removes advertisement for Algorithm A 576 B. Signer waits for cached copies of earlier signature policy to 577 expire 579 C. Signer stops signing with Algorithm A 581 3.3.2. Verifier transition strategy 583 The actions of the verifier are independent of the signer's actions 584 and do not need to be performed in a particular sequence. The 585 verifier may make a decision to cease accepting algorithm A without 586 first deploying support for algorithm B. Similarly a verifier may be 587 upgraded to support algorithm B without requiring algorithm A to be 588 withdrawn. The decisions of the verifier must make are therefore: 590 o The verifier MAY change the degree of confidence associated with 591 any signature at any time, including determining that a given 592 signature algorithm provides a limited assurance of authenticity 593 at a given key strength. 595 * A verifier MAY evaluate signature records in any order it 596 chooses, including using the signature algorithm to choose the 597 order. 599 o The verifier MAY make a determination that Algorithm A does not 600 offer a useful level of security, or that the cost of verifying 601 the signature is less than the value of doing so. 603 * In this case the verifier would ignore signatures created using 604 algorithm A and references to algorithm A in policy records 605 would be treated as if the algorithm were not implemented. 607 o The verifier MAY decide to add support for additional signature 608 algorithms at any time. 610 * The verifier MAY add support for algorithm B at any time. 612 4. Verifying 614 4.1. Verifier 616 Verifiers should treat the result of the verification step as an 617 input to the message evaluation process rather than as providing a 618 final decision. The knowledge that a message is authentically sent 619 by a domain does not say much about the legitimacy of the message, 620 unless the characteristics of the domain claiming responsibility are 621 known. 623 In particular, verifiers should NOT automatically assume that an 624 email message that does not contain a signature, or that contains a 625 signature that does not verify, is forged. Verifiers should treat a 626 signature that fails to verify the same as if no signature were 627 present. NOTE: THE ABOVE MAY BE MODIFIED BY SSP/ASP 629 Verification is performed within an ADMD that wishes to make 630 assessments based upon the DKIM signature's domain name. Any 631 component within the ADMD that handles messages, whether in transit 632 or being delivered, can do the verifying and subsequent assessments. 633 Verification and assessment might occur within the same software 634 mechanism, such as a Boundary MTA, or an MDA. Or they may be 635 separated, such as having verification performed by the Boundary MTA 636 and assessment performed by the MDA. 638 As with the signing process, choice of service venues for 639 verification and assessment -- such as filtering or presentation to 640 the recipient user -- depend on trade-offs for flexibility, control, 641 and operational ease. An added concern is that the linkage between 642 verification and assessment entails essential trust: the assessment 643 module must have a strong basis for believing that the verification 644 information is correct. 646 4.2. DNS Client 648 The primary means of publishing DKIM key information, initially, is 649 through DNS TXT records. Some DNS client software might have 650 problems obtaining these records; as DNS client software improves 651 this will not be a concern. 653 4.3. Boundary Enforcement 655 In order for an assessment module to trust the information it 656 receives about verification (e.g., Authentication-Results header 657 fields), it must eliminate verification information originating from 658 outside the ADMD in which the assessment mechanism operates. As a 659 matter of friendly practice, it is equally important to make sure 660 that verification information generated within the ADMD not escape 661 outside of it. 663 In most environments, the easiest way to enforce this is to place 664 modules in the receiving and sending Boundary MTA(s) that strip any 665 existing verification information. 667 4.4. Filtering Software 669 Developers of filtering schemes designed to accept DKIM 670 authentication results as input should be aware that their 671 implementations will be subject to counter-attack by email abusers. 672 The efficacy of a filtering scheme cannot therefore be determined by 673 reference to static test vectors alone; resistance to counter attack 674 must also be considered. 676 Naive learning algorithms that only consider the presence or absence 677 of a verified DKIM signature, without considering more information 678 about the message, are vulnerable to an attack in which spammers or 679 other malefactors sign all their mail, thus creating a large negative 680 value for presence of a DKIM signature in the hope of discouraging 681 widespread use. 683 If heuristic algorithms are employed, they should be trained on 684 feature sets that sufficiently reveal the internal structure of the 685 DKIM responses. In particular the algorithm should consider the 686 domains purporting to claim responsibility for the signature, rather 687 than the existence of a signature or not. 689 Unless a scheme can correlate the DKIM signature with accreditation 690 or reputation data, the presence of a DKIM signature should be 691 ignored. 693 5. DKIM Deployment Considerations for Email Agents 695 5.1. Email Infrastructure Agents 697 It is expected that the most common venue for a DKIM implementation 698 will be within the infrastructure of an organization's email service, 699 such as a department or a boundary MTA. 701 Outbound: An MSA or Outbound MTA should allow for the automatic 702 verification of the MTA configuration such that the MTA can 703 generate an operator alert if it determines that it is (1) an 704 edge MTA, and (2) configured to send email messages that do not 705 comply with the published DKIM sending policy. 707 An outbound MTA should be aware that users may employ MUAs that 708 add their own signatures and be prepared to take steps 709 necessary to ensure that the message sent is in compliance with 710 the advertised email sending policy. 712 [[anchor42: MUAs being able to sign is a security 713 consideration; MUAs are more prone to vulnerabilities, so an 714 MUA having direct access to signing keys is a security concern; 715 general MUA vulnerability came up during the IETF Security 716 Directorate review of draft-kucherawy-sender-auth-header]] 718 Inbound: An inbound MTA or an MDA that does not support DKIM 719 should avoid modifying messages in ways that prevent 720 verification by other MTAs, or MUAs to which the message may be 721 forwarded. 723 An inbound MTA or an MDA may incorporate an indication of the 724 verification results into the message, such as using an 725 Authentication-Results header field. 726 [I-D.kucherawy-sender-auth-header] 728 Intermediaries: An email intermediary is both an inbound and 729 outbound MTA. Each of the requirements outlined in the 730 sections relating to MTAs apply. If the intermediary modifies 731 a message in a way that breaks the signature, the intermediary 733 + should deploy abuse filtering measures on the inbound mail, 734 and 736 + MAY remove all signatures that will be broken 738 In addition the intermediary MAY: 740 + Verify the message signature prior to modification. 742 + Incorporate an indication of the verification results into 743 the message, such as using an Authentication-Results header 744 field. [I-D.kucherawy-sender-auth-header] 746 + Sign the modified message including the verification results 747 (e.g., the Authentication-Results header field). 749 5.2. Mail User Agent 751 DKIM is designed to support deployment and use in email components 752 other than an MUA. However an MUA MAY also implement DKIM features 753 directly. 755 Outbound: If an MUA is configured to send email directly, rather 756 than relay it through an outbound MSA, the MUA should be 757 considered as if it were an outbound MTA for the purposes of 758 DKIM. An MUA MAY support signing even if mail is to be relayed 759 through an outbound MSA. In this case the signature applied by 760 the MUA may be in addition to any MSA signature. 762 Inbound: An MUA MAY rely on a report of a DKIM signature 763 verification that took place at some point in the inbound MTA 764 path (e.g., an Authentication-Results header field), or an MUA 765 MAY perform DKIM signature verification directly. A verifying 766 MUA should allow for the case where mail is modified in the 767 inbound MTA path. 769 It is common for components of an ADMD's email infrastructure to do 770 violence to a message, such as to render a DKIM signature invalid. 771 Hence, users of MUAs that support DKIM signing and/or verifying need 772 a basis for knowing that their associated email infrastructure will 773 not break a signature. 775 6. Migrating from DomainKeys 777 6.1. Signing 779 DNS Records: DKIM is upwardly compatible with existing 780 DomainKeys (DK) [RFC4870] DNS records, so that a DKIM module 781 does not automatically require additional DNS administration. 782 However DKIM has enhanced the DomainKeys DNS key record format 783 by adding several additional optional parameters. 785 [[anchor46: Explicit "g=" has different meaning in DomainKeys 786 and DKIM, which has been an interoperability issue in the past 787 (DomainKeys interprets that as "match any" while DKIM 788 interprets it as "match none")]] 790 Boundary MTA: The principal use of DomainKeys is at Boundary 791 MTAs. Because no operational transition is ever instantaneous, 792 it is not adviseable for existing DomainKeys signers to switch 793 to DKIM without continuing to perform DomainKeys signing. A 794 signer should add a DKIM signature to a message that also has a 795 DomainKeys signature, until such time as DomainKeys receive- 796 side support is sufficiently reduced. With respect to signing 797 policies, a reasonable, initial approach is to use DKIM 798 signatures in the same way as DomainKeys signatures are already 799 being used. 801 6.2. Verifying 803 DNS Client: DNS queries for the DKIM key record use the same 804 Domain Name naming conventions as were used for DomainKeys, and 805 the same basic record format. No changes to the DNS client 806 should be required. 808 Verifying module: See the section on Signing above. 810 7. Example Uses 812 A DKIM signature tells the signature verifier that the owner of a 813 particular domain name accepts responsibility for the message. 814 Combining this information with information that allows the history 815 of the domain name owner to be assessed may allow processing the 816 message, based on the probability that the message is likely to be 817 trustworthy, or not, without the need for heuristic content analysis. 819 7.1. Protection of Internal Mail 821 One identity is particularly amenable to easy and accurate 822 assessment: The organization's own identity. Members of an 823 organization tend to trust messages that purport to be from within 824 that organization. However Internet Mail does not provide a 825 straightforward means of determining whether such mail is, in fact, 826 from within the organization. DKIM can be used to remedy this 827 exposure. If the organization signs all of its mail, then its 828 boundary MTAs can look for mail purporting to be from the 829 organization but does not contain a verifiable signature. Such mail 830 can be presumed to be spurious. 832 WHAT ABOUT MAIL TO A MAILING LIST THAT COMES BACK WITH A BROKEN 833 SIGNATURE???? Need to include some of the breakage examples from 834 ADSP spec. 836 7.2. Recipient-based Assessments 838 Recipients of large volumes of email can internally generate 839 reputation data for email senders. Recipients of smaller volumes of 840 messages are likely to need to acquire reputation data from a third 841 party. In either case the use of reputation data is intrinsically 842 limited to email senders that have established a prior history of 843 sending messages. 845 In fact, an email receiving service may be in a position to establish 846 bilateral agreements with particular senders, such as business 847 partners or trusted bulk sending services. Although it is not 848 practical for each recipient to accredit every sender, the definition 849 of core networks of explicit trust can be quite useful. 851 7.2.1. Third-party Reputation and Accreditation Services 853 For scaling efficiency, it is appealing to use Trusted Third Party 854 reputation and accreditation services, to allow an email sender to 855 obtain a single assessment that is then recognized by every email 856 recipient that recognizes the Trusted Third Party. 858 7.3. DKIM Support in the Client 860 The DKIM specification is expected to be used primarily between 861 Boundary MTAs, or other infrastructure components of the originating 862 and receiving ADMDs. However there is nothing in DKIM that is 863 specific to those venues. In particular, it should be possible to 864 support signing and verifying in MUAs. 866 DKIM requires that all verifiers treat messages with signatures that 867 do not verify as if they are unsigned. If verification in the client 868 is to be acceptable to users, it is also essential that successful 869 verification of a signature not result in a less than satisfactory 870 user experience compared to leaving the message unsigned. 872 7.4. Per user signatures 874 Although DKIM's use of domain names is optimized for a scope of 875 organization-level signing, it is possible to administer sub-domains 876 and/or selectors in a way that supports per-user signing. 878 NOTE: As stated earlier, it is important to distinguish between the 879 use of selectors for differential administration of keys, versus 880 the use of sub-domains for differential reputations. It's also 881 probably a good idea to note that receivers are unlikely to pay 882 attention to reputation at a user granularity even if it's 883 technically feasible to publish it. 885 As a constraint on an authorized DKIM signing agent, its associated 886 key record can specify restrictions on the email addresses permitted 887 to be signed with that domain and key. A typical intent of this 888 feature is to allow a company to delegate the signing authority for 889 bulk marketing communications without the risk of effectively 890 delegating the authority to sign messages purporting to come from the 891 domain-owning organization's CEO. 893 NOTE: Any scheme that involves maintenance of a significant number 894 of public keys is likely to require infrastructure enhancements, 895 to support that management. For example, a system in which the 896 end user is required to generate a public key pair and transmit it 897 to the DNS administrator out of band is not likely to meet 898 acceptance criteria for either usability or security. 900 8. Security Considerations 902 TBD 904 9. IANA Considerations 906 TBD 908 10. Acknowledgements 910 TBD 912 11. Informative References 914 [I-D.ietf-openpgp-rfc2440bis] 915 Callas, J., "OpenPGP Message Format", 916 draft-ietf-openpgp-rfc2440bis-22 (work in progress), 917 April 2007. 919 [I-D.kucherawy-sender-auth-header] 920 Kucherawy, M., "Message Header Field for Indicating 921 Message Authentication Status", 922 draft-kucherawy-sender-auth-header-17 (work in progress), 923 October 2008. 925 [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement 926 for Internet electronic mail: Part I: Message encipherment 927 and authentication procedures", RFC 989, February 1987. 929 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 930 STD 13, RFC 1034, November 1987. 932 [RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME 933 Object Security Services", RFC 1848, October 1995. 935 [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message 936 Exchange Formats", RFC 1991, August 1996. 938 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 939 "OpenPGP Message Format", RFC 2440, November 1998. 941 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 942 April 2001. 944 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 945 April 2001. 947 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 948 "MIME Security with OpenPGP", RFC 3156, August 2001. 950 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, 951 August 2001. 953 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 954 Extensions (S/MIME) Version 3.1 Message Specification", 955 RFC 3851, July 2004. 957 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys 958 Identified Mail (DKIM)", RFC 4686, September 2006. 960 [RFC4870] Delany, M., "Domain-Based Email Authentication Using 961 Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, 962 May 2007. 964 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 965 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 966 Signatures", RFC 4871, May 2007. 968 Authors' Addresses 970 Tony Hansen 971 AT&T Laboratories 972 200 Laurel Ave. 973 Middletown, NJ 07748 974 USA 976 Email: tony+dkimov@maillennium.att.com 978 Phillip Hallam-Baker 979 VeriSign Inc. 981 Email: pbaker@verisign.com 983 Dave Crocker 984 Brandenburg InternetWorking 985 675 Spruce Dr. 986 Sunnyvale, CA 94086 987 USA 989 Email: dcrocker@bbiw.net 991 Ellen Siegel 992 Constant Contact, Inc. 993 1601 Trapelo Rd, Ste 329 994 Waltham, MA 02451 995 USA 997 Email: esiegel@constantcontact.com 999 Full Copyright Statement 1001 Copyright (C) The IETF Trust (2008). 1003 This document is subject to the rights, licenses and restrictions 1004 contained in BCP 78, and except as set forth therein, the authors 1005 retain all their rights. 1007 This document and the information contained herein are provided on an 1008 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1009 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1010 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1011 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1012 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1013 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1015 Intellectual Property 1017 The IETF takes no position regarding the validity or scope of any 1018 Intellectual Property Rights or other rights that might be claimed to 1019 pertain to the implementation or use of the technology described in 1020 this document or the extent to which any license under such rights 1021 might or might not be available; nor does it represent that it has 1022 made any independent effort to identify any such rights. Information 1023 on the procedures with respect to rights in RFC documents can be 1024 found in BCP 78 and BCP 79. 1026 Copies of IPR disclosures made to the IETF Secretariat and any 1027 assurances of licenses to be made available, or the result of an 1028 attempt made to obtain a general license or permission for the use of 1029 such proprietary rights by implementers or users of this 1030 specification can be obtained from the IETF on-line IPR repository at 1031 http://www.ietf.org/ipr. 1033 The IETF invites any interested party to bring to its attention any 1034 copyrights, patents or patent applications, or other proprietary 1035 rights that may cover technology that may be required to implement 1036 this standard. Please address the information to the IETF at 1037 ietf-ipr@ietf.org.