idnits 2.17.1 draft-ietf-dkim-deployment-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 941. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 952. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 959. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 965. 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 107: '... implementations SHOULD provide a conv...' RFC 2119 keyword, line 110: '...ted however, such mechanism(s) MUST be...' RFC 2119 keyword, line 119: '... SHOULD support use of cryptographic...' RFC 2119 keyword, line 140: '...against other processes SHOULD be used...' RFC 2119 keyword, line 141: '...ticular, great care MUST be taken when...' (25 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 (February 25, 2008) is 5902 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-openpgp-rfc2440bis' is defined on line 850, but no explicit reference was found in the text == Unused Reference: 'RFC0989' is defined on line 861, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 865, but no explicit reference was found in the text == Unused Reference: 'RFC1848' is defined on line 868, but no explicit reference was found in the text == Unused Reference: 'RFC1991' is defined on line 871, but no explicit reference was found in the text == Unused Reference: 'RFC2440' is defined on line 874, but no explicit reference was found in the text == Unused Reference: 'RFC2821' is defined on line 877, but no explicit reference was found in the text == Unused Reference: 'RFC2822' is defined on line 880, but no explicit reference was found in the text == Unused Reference: 'RFC3156' is defined on line 883, but no explicit reference was found in the text == Unused Reference: 'RFC3164' is defined on line 886, but no explicit reference was found in the text == Unused Reference: 'RFC3851' is defined on line 889, but no explicit reference was found in the text == Unused Reference: 'RFC4686' is defined on line 893, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-kucherawy-sender-auth-header-11 -- 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: August 28, 2008 VeriSign Inc. 6 D. Crocker 7 Brandenburg InternetWorking 8 February 25, 2008 10 DomainKeys Identified Mail (DKIM) Development, Deployment and Operations 11 draft-ietf-dkim-deployment-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 28, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 DomainKeys Identified Mail (DKIM) associates a "responsible" identity 45 with a message and provides a means of verifying that the association 46 is legitimate. [RFC4871] DKIM defines a domain-level authentication 47 framework for email using public-key cryptography and key server 48 technology. This permits verifying the source or intermediary for a 49 message, as well as the contents of messages. The ultimate goal of 50 this framework is to permit a signing domain to assert responsibility 51 for sending a message, thus proving and protecting the identity 52 associated with the message and the integrity of the messages itself, 53 while retaining the functionality of Internet email as it is known 54 today. Such protection of email identity may assist in the global 55 control of "spam" and "phishing". This document provides 56 implementation, deployment, operational and migration considerations 57 for DKIM. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Development . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. DKIM Signing Software . . . . . . . . . . . . . . . . . . 3 64 2.2. General Coding Criteria for Cryptographic Applications . . 3 65 2.3. Mailing List Manager Software . . . . . . . . . . . . . . 4 66 2.4. Email Infrastructure Agents . . . . . . . . . . . . . . . 5 67 2.5. Filtering Software . . . . . . . . . . . . . . . . . . . . 6 68 2.6. DNS Server Software . . . . . . . . . . . . . . . . . . . 6 69 3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.2. Verifying . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.3. Key Management Deployment . . . . . . . . . . . . . . . . 9 73 3.4. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 10 74 3.5. Mail User Agent . . . . . . . . . . . . . . . . . . . . . 11 75 3.6. Transition Strategy . . . . . . . . . . . . . . . . . . . 12 76 3.7. Migrating from DomainKeys . . . . . . . . . . . . . . . . 13 77 4. On-going Operations . . . . . . . . . . . . . . . . . . . . . 14 78 4.1. DNS Signature Record Installation Considerations . . . . . 14 79 4.2. Private Key Management . . . . . . . . . . . . . . . . . . 16 80 5. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 5.1. Protection of Internal Mail . . . . . . . . . . . . . . . 17 82 5.2. Recipient-based Assessments . . . . . . . . . . . . . . . 17 83 5.3. DKIM Support in the Client . . . . . . . . . . . . . . . . 18 84 5.4. Per user signatures . . . . . . . . . . . . . . . . . . . 18 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 87 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 88 9. Informative References . . . . . . . . . . . . . . . . . . . . 19 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 90 Intellectual Property and Copyright Statements . . . . . . . . . . 21 92 1. Introduction 94 There are many areas to be considered when deploying DomainKeys 95 Identified Mail (DKIM). This document provides practical tips for: 96 those who are developing DKIM software, mailing list managers, 97 filtering strategies based on the output from DKIM verification, and 98 DNS servers; those who are deploying DKIM software, keys, mailing 99 list software, and migrating from DomainKeys; and those who are 100 responsible for the on-going operations of an email infrastructure 101 that has deployed DKIM. 103 2. Development 105 2.1. DKIM Signing Software 107 Signer implementations SHOULD provide a convenient means of 108 generating DNS key records corresponding to the signer configuration. 109 Support for automatic insertion of key records into the DNS is also 110 highly desirable. If supported however, such mechanism(s) MUST be 111 properly authenticated. 113 A means of verifying that the signer configuration is compatible with 114 the signature policy is also highly desirable. 116 Disclosure of a private signature key component to a third party 117 allows that third party to impersonate the sender. The protection of 118 private signature key data is therefore a critical concern. Signers 119 SHOULD support use of cryptographic hardware providing key management 120 features. 122 2.2. General Coding Criteria for Cryptographic Applications 124 NOTE: This section could possibly be changed into a reference to 125 something else, such as another rfc. 127 Correct implementation of a cryptographic algorithm is a necessary 128 but not a sufficient condition for the coding of cryptographic 129 applications. Coding of cryptographic libraries requires close 130 attention to security considerations that are unique to cryptographic 131 applications. 133 In addition to the usual security coding considerations, such as 134 avoiding buffer or integer overflow and underflow, implementers 135 should pay close attention to management of cryptographic private 136 keys and session keys, ensuring that these are correctly initialized 137 and disposed of. 139 Operating system mechanisms that permit the confidentiality of 140 private keys to be protected against other processes SHOULD be used 141 when available. In particular, great care MUST be taken when 142 releasing memory pages to the operating system to ensure that private 143 key information is not disclosed to other processes. 145 Certain implementations of public key algorithms such as RSA may be 146 vulnerable to a timing analysis attack. 148 Support for cryptographic hardware providing key management 149 capabilities is strongly encouraged. In addition to offering 150 performance benefits, many cryptographic hardware devices provide 151 robust and verifiable management of private keys. 153 Fortunately appropriately designed and coded cryptographic libraries 154 are available for most operating system platforms under license terms 155 compatible with commercial, open source and free software license 156 terms. Use of standard cryptographic libraries is strongly 157 encouraged. These have been extensively tested, reduce development 158 time and support a wide range of cryptographic hardware. 160 2.3. Mailing List Manager Software 162 A mailing list often provides facilities to its administrator to 163 manipulate parts of the mail messages that flow through the list. 164 The desired goal is that messages flowing through the mailing list 165 will be verifiable by the recipient as being from the list, or 166 failing that, as being from the individual list members. 168 In most cases, the list and/or its mail host SHOULD add its own DKIM 169 signature to list mail. This could be done in the list management 170 software, in an outgoing MSA or MTA, or both. List management 171 software often makes modifications to messages that will break 172 incoming signatures, such as adding subject tags, adding message 173 headers or footers, and adding, deleting, or reordering MIME parts. 174 By adding its own signature after these modifications, the list 175 provides a verifiable, recognizable signature for list recipients. 177 In some cases, the modifications made by the mailing list software 178 are simple enough that signatures on incoming messages will still be 179 verifiable after being remailed by the list. It is still preferable 180 that the list sign its mail so that recipients can distinguish 181 between mail sent through the list and mail sent directly to a list 182 member. In the absence of a list signature, a recipient may still be 183 able to recognize and use the original signatures of the list 184 members. 186 2.4. Email Infrastructure Agents 188 It is expected that the most common venue for a DKIM implementation 189 will be within the infrastructure of an organization's email service, 190 such as a department or a boundary MTA. 192 Outbound: An MSA or Outbound MTA should allow for the automatic 193 verification of the MTA configuration such that the MTA can 194 generate an operator alert if it determines that it is (1) an 195 edge MTA, and (2) configured to send email messages that do not 196 comply with the published DKIM sending policy. 198 An outbound MTA should be aware that users may employ MUAs that 199 add their own signatures and be prepared to take steps 200 necessary to ensure that the message sent is in compliance with 201 the advertised email sending policy. 203 Inbound: An inbound MTA or an MDA that does not support DKIM 204 should avoid modifying messages in ways that prevent 205 verification by other MTAs, or MUAs to which the message may be 206 forwarded. 208 An inbound MTA or an MDA may incorporate an indication of the 209 verification results into the message, such as using an 210 Authentication-Results header. 211 [I-D.kucherawy-sender-auth-header] 213 Intermediaries: An email intermediary is both an inbound and 214 outbound MTA. Each of the requirements outlined in the 215 sections relating to MTAs apply. If the intermediary modifies 216 a message in a way that breaks the signature, the intermediary 218 + SHOULD deploy abuse filtering measures on the inbound mail, 219 and 221 + MAY remove all signatures that will be broken 223 In addition the intermediary MAY: 225 + Verify the message signature prior to modification. 227 + Incorporate an indication of the verification results into 228 the message, such as using an Authentication-Results header. 229 [I-D.kucherawy-sender-auth-header] 231 + Sign the modified message including the verification results 232 (e.g., the Authentication-Results header). 234 2.5. Filtering Software 236 Developers of filtering schemes designed to accept DKIM 237 authentication results as input should be aware that their 238 implementations will be subject to counter-attack by email abusers. 239 The efficacy of a filtering scheme cannot therefore be determined by 240 reference to static test vectors alone; resistance to counter attack 241 must also be considered. 243 Naive learning algorithms that only consider the presence or absence 244 of a verified DKIM signature, without considering more information 245 about the message, are vulnerable to an attack in which a spammer or 246 other malefactor signs all their mail, thus creating a large negative 247 value for presence of a DKIM signature in the hope of discouraging 248 widespread use. 250 If heuristic algorithms are employed, they should be trained on 251 feature sets that sufficiently reveal the internal structure of the 252 DKIM responses. In particular the algorithm should consider the 253 domains purporting to claim responsibility for the signature, rather 254 than the existence of a signature or not. 256 Unless a scheme can correlate the DKIM signature with accreditation 257 or reputation data, the presence of a DKIM signature SHOULD be 258 ignored. 260 2.6. DNS Server Software 262 At a minimum, a DNS server that handles queries for DKIM key records 263 must allow the server administrators to add free-form TXT records. 264 It would be better if the the DKIM records could be entered using a 265 structured form, supporting the DKIM-specific fields. 267 3. Deployment 269 This section describes the basic steps for introducing DKIM into an 270 organization's email service operation. The considerations are 271 divided between the generating DKIM signatures (Signing) and the 272 processing of messages that contain a DKIM signature (Verifying). 274 3.1. Signing 276 Creating messages that have DKIM signatures requires a modification 277 to only two portions of the email service: 279 o Addition of relevant DNS information. 281 o Addition of the signature by a trusted module within the 282 organization's email handling service. 284 The signing module uses the appropriate private key to create a 285 signature. The means by which the signing module obtains the private 286 key is not specified by DKIM. Given that DKIM is intended for use 287 during email transit, rather than for long-term storage, it is 288 expected that keys will be changed regularly. Clearly this means 289 that key information should not be hard-coded into software. 291 3.1.1. DNS Records 293 A receiver attempting to verify a DKIM signature must obtain the 294 public key that is associated with the signature for that message. 295 The DKIM-Signature header in the message will specify the basic 296 domain name doing the signing and the selector to be used for the 297 specific public key. Hence, the relevant 298 ._domainkey. DNS record needs to contain a 299 DKIM-related resource record (RR) that provides the public key 300 information. 302 The administrator of the zone containing the relevant domain name 303 adds this information. Initial DKIM DNS information is contained 304 within TXT RRs. DNS administrative software varies considerably in 305 its abilities to add new types of DNS records. 307 3.1.2. Signing Module 309 The module doing signing can be placed anywhere within an 310 organization's trusted Administrative Management Domain (ADMD); 311 common choices are expected to be department-level posting and 312 delivering agents, as well as boundary MTAs to the open Internet. 313 (Note that it is entirely acceptable for MUAs to perform signing and 314 verification.) Hence the choice among the modules depends upon 315 software development and administrative overhead tradeoffs. One 316 perspective that helps resolve this choice is the difference between 317 the flexibility of use by systems at (or close to) the MUA, versus 318 the centralized control that is more easily obtained by implementing 319 the mechanism "deeper" into the organization's email infrastructure, 320 such as at its boundary MTA. 322 3.1.3. Signing Policies and Practices 324 Every organization (ADMD) will have its own policies and practices 325 for deciding when to sign messages and with what domain name and key 326 (selector). Examples include signing all mail, signing mail from 327 particular email addresses, or signing mail from particular sub- 328 domains. Given this variability, and the likelihood that signing 329 practices will change over time, it will be useful to have these 330 decisions represented in some sort of configuration information, 331 rather than being more deeply coded into the signing software. 333 3.2. Verifying 335 3.2.1. Verifier 337 Verifiers SHOULD treat the result of the verification step as an 338 input to the message evaluation process rather than as providing a 339 final decision. The knowledge that a message is authentically sent 340 by a domain does not say much about the legitimacy of the message, 341 unless the characteristics of the domain claiming responsibility are 342 known. 344 In particular, verifiers SHOULD NOT automatically assume that an 345 email message that does not contain a signature, or that contains a 346 signature that does not verify, is forged. Verifiers should treat a 347 signature that fails to verify the same as if no signature were 348 present. NOTE: THE ABOVE MAY BE MODIFIED BY SSP/ASP 350 Verification is performed within an ADMD that wishes to make 351 assessments based upon the DKIM signature's domain name. Any 352 component within the ADMD that handles messages, whether in transit 353 or being delivered, can do the verifying and subsequent assessments. 354 Verification and assessment might occur within the same software 355 mechanism, such as a Boundary MTA, or an MDA. Or they may be 356 separated, such as having verification performed by the Boundary MTA 357 and assessment performed by the MDA. 359 As with the signing process, choice of service venues for 360 verification and assessment -- such as filtering or presentation to 361 the recipient user -- depend on trade-offs for flexibility, control, 362 and operational ease. An added concern is that the linkage between 363 verification and assessment entails essential trust: the assessment 364 module MUST have a strong basis for believing that the verification 365 information is correct. 367 3.2.2. DNS Client 369 The primary means of publishing DKIM key information, initially, is 370 initially through DNS TXT records. Some DNS client software might 371 have problems obtaining these records; as DNS client software 372 improves this will not be a concern. 374 3.2.3. Boundary Enforcement 376 In order for an assessment module to trust the information it 377 receives about verification (e.g., Authentication-Results headers), 378 it MUST eliminate verification information originating from outside 379 the ADMD in which the assessment mechanism operates. As a matter of 380 friendly practice, it is equally important to make sure that 381 verification information generated within the ADMD not escape outside 382 of it. 384 In most environments, the easiest way to enforce this is to place 385 modules in the receiving and sending Boundary MTA(s) that strip any 386 existing verification information. 388 3.3. Key Management Deployment 390 More to be added 392 3.3.1. First Party Key Management 394 Selectors Selectors are assigned according to the administrative 395 needs of the signing domain, such as for rolling over to a new key 396 or for delegating of the right to authenticate a portion of the 397 namespace to a trusted third party. 399 Examples include: jun2005.eng._domainkey.example.com 401 widget.promotion._domainkey.example.com 403 NOTE: It is intended that assessments of DKIM identities be based 404 on the domain name, and not include the selector. This permits 405 the selector to be used only for key administration, rather than 406 having an effect on reputation assessment. 408 3.3.2. Third Party Key Management 410 ???????????????? 3rd party generates the public / private key pair 411 and sends the public key to be published in the DNS. 413 3.3.3. Signer Actions 415 All Signers SHOULD: 417 o Include any existing Sender header field in the signed header 418 field list, if the Sender header field exists. 420 Signers wishing to avoid the use of Third-Party Signatures SHOULD do 421 everything listed above, and also: 423 o Include the Sender header field name in the header field list 424 ("h=" tag) under all circumstances, even if the Sender header 425 field does not exist in the header block. This prevents another 426 entity from adding a Sender header field. 428 o Publish Signing Practices that do not sanction the use of Third- 429 Party Signatures. 431 3.4. Mailing Lists 433 There are several forms of mailing lists, which interact with signing 434 in different ways. 436 o "Verbatim" mailing lists send messages without modification 437 whatsoever. They are often implemented as MTA-based aliases. 438 Since they do not modify the message, signatures are unaffected 439 and will continue to verify. It is not necessary for the 440 forwarder to re-sign the message; however, some may choose to do 441 so in order to certify that the message was sent through the list. 443 o "Digesting" mailing lists collect together one or more postings 444 and then retransmit them, often on a nightly basis, to the 445 subscription list. These are essentially entirely new messages 446 which must be independently authored (that is, they will have a 447 "From" header field referring to the list, not the submitters) and 448 signed by the Mailing List Manager itself, if they are signed at 449 all. 451 o "Resending" mailing lists receive a message, modify it (often to 452 add "unsubscribe" information or advertising), and immediately 453 resend that message to the subscription list. They are 454 problematic because they usually do not change the "From" header 455 field of the message, but they do invalidate the signature in the 456 process of modifying the message. 458 The first two cases act in obvious ways and do not require further 459 discussion. The remainder of this session applies only to the third 460 case. 462 3.4.1. Mailing List Manager Actions 464 Mailing List Managers should make every effort to ensure that 465 messages that they relay and which have Valid Signatures upon receipt 466 also have Valid Signatures upon retransmission. In particular, 467 Mailing List Managers that modify the message in ways that break 468 existing signatures SHOULD: 470 o Verify any existing DKIM Signatures. A DKIM-aware Mailing List 471 Manager MUST NOT re-sign an improperly signed message in such a 472 way that would imply that the existing signature is acceptable. 474 o Apply regular anti-spam policies. A Mailing List Manager SHOULD 475 apply message content security policy just as they would messages 476 destined for an individual user's mailbox. In fact, a Mailing 477 List Manager might apply a higher standard to messages destined to 478 a mailing list than would normally be applied to individual 479 messages. 480 NON-NORMATIVE RATIONALE: Since reputation will accrue to signers, 481 Mailing List Managers should verify the source and content of 482 messages before they are willing to sign lest their reputation be 483 sullied by nefarious parties. 485 o Add a Sender header field using a valid address pointing back to 486 the Mailing List Administrator or an appropriate agent (such as an 487 "owner-" or a "-request" address). 489 o Sign the resulting message with a signature that is valid for the 490 Sender header field address. The Mailing List Manager SHOULD NOT 491 sign messages for which they are unwilling to accept 492 responsibility. 494 Mailing List Managers MAY: 496 o Reject messages with signatures that do not verify or are 497 otherwise Suspicious. 499 3.5. Mail User Agent 501 DKIM is designed to support deployment and use in email components 502 other than an MUA. However an MUA MAY also implement DKIM features 503 directly. 505 Outbound: If an MUA is configured to send email directly, rather 506 than relayed through an outbound MSA, the MUA SHOULD be 507 considered as if it were an outbound MTA for the purposes of 508 DKIM. An MUA MAY support signing even if mail is to be relayed 509 through an outbound MSA. In this case the signature applied by 510 the MUA may be in addition to any MSA signature. 512 Inbound: An MUA MAY rely on a report of a DKIM signature 513 verification that took place at some point in the inbound MTA 514 path (e.g., an Authentication-Results header), or an MUA MAY 515 perform DKIM signature verification directly. A verifying MUA 516 SHOULD allow for the case where mail is modified in the inbound 517 MTA path. 519 It is common for components of an ADMD's email infrastructure to do 520 violence to a message, such as to render a DKIM signature invalid. 521 Hence, users of MUAs that support DKIM signing and/or verifying need 522 a basis for knowing that their associated email infrastructure will 523 not break a signature. 525 3.6. Transition Strategy 527 Deployment of a new signature algorithm without a 'flag day' requires 528 a transition strategy such that signers and verifiers can phase in 529 support for the new algorithm independently, and (if necessary) phase 530 out support for the old algorithm independently. 532 [Note: this section assumes that a security policy mechanism exists. 533 It is subject to change.] 535 DKIM achieves these requirements through two features: First a signed 536 message may contain multiple signatures created by the same signer. 537 Secondly the security policy layer allows the signing algorithms in 538 use to be advertised, thus preventing a downgrade attack. 540 3.6.1. Signer transition strategy 542 Let the old signing algorithm be A, the new signing algorithm be B. 543 The sequence of events by which a Signer may introduce the new 544 signing algorithm B, without disruption of service to legacy 545 verifiers, is as follows: 547 1. Signer signs with algorithm A 549 A. Signer advertises that it signs with algorithm A 551 2. Signer signs messages twice, with both algorithm A and algorithm 552 B 554 A. The signer tests new signing configuration 556 B. Signer advertises that it signs with either algorithm A or 557 algorithm B 559 3. Signer determines that support for Algorithm A is no longer 560 necessary 562 4. Signer determines that support for algorithm A is to be withdrawn 563 A. Signer removes advertisement for Algorithm A 565 B. Signer waits for cached copies of earlier signature policy to 566 expire 568 C. Signer stops signing with Algorithm A 570 3.6.2. Verifier transition strategy 572 The actions of the verifier are independent of the signer's actions 573 and do not need to be performed in a particular sequence. The 574 verifier may make a decision to cease accepting algorithm A without 575 first deploying support for algorithm B. Similarly a verifier may be 576 upgraded to support algorithm B without requiring algorithm A to be 577 withdrawn. The decisions of the verifier must make are therefore: 579 o The verifier MAY change the degree of confidence associated with 580 any signature at any time, including determining that a given 581 signature algorithm provides a limited assurance of authenticity 582 at a given key strength. 584 * A verifier MAY evaluate signature records in any order it 585 chooses, including using the signature algorithm to choose the 586 order. 588 o The verifier MAY make a determination that Algorithm A does not 589 offer a useful level of security, or that the cost of verifying 590 the signature is less than the value of doing so. 592 * In this case the verifier would ignore signatures created using 593 algorithm A and references to algorithm A in policy records 594 would be treated as if the algorithm were not implemented. 596 o The verifier MAY decide to add support for additional signature 597 algorithms at any time. 599 * The verifier MAY add support for algorithm B at any time. 601 3.7. Migrating from DomainKeys 603 3.7.1. Signing 605 DNS Records: DKIM is upwardly compatible with existing 606 DomainKeys (DK) [RFC4870] DNS records, so that a DKIM module 607 does not automatically require additional DNS administration! 608 However DKIM has enhanced the DomainKeys DNS key record format 609 by adding several additional optional parameters. 611 Boundary MTA: The principle use of DomainKeys is at Boundary 612 MTAs. Because no operational transition is ever instantaneous, 613 it is not adviseable for existing DomainKeys signers to switch 614 to DKIM without continuing to perform DomainKeys signing. A 615 signer should add a DKIM signature to a message that also has a 616 DomainKeys signature, until such time as DomainKeys receive- 617 side support is sufficiently reduced. With respect to signing 618 policies, a reasonable, initial approach is to use DKIM 619 signatures in the same way as DomainKeys signatures are already 620 being used. 622 3.7.2. Verifying 624 DNS Client: DNS queries for the DKIM key record, use the same 625 Domain Name naming conventions as were used for DomainKeys, and 626 the same basic record format. No changes to the DNS client 627 should be required. 629 Verifying module: See the section on Signing above. 631 4. On-going Operations 633 This section describes the basic steps for operation of email systems 634 that use DKIM, after the capability has initially been deployed. The 635 primary considerations are: 637 o the upkeep of the selector files, and 639 o the security of the private keys. 641 4.1. DNS Signature Record Installation Considerations 643 Even with use of the DNS, one challenge is that DNS record management 644 is usually operated by an administrative staff that is different from 645 those who operate an organization's email service. In order to 646 ensure that DKIM DNS records are accurate, this imposes a requirement 647 for careful coordination between the two operations groups. 649 The key point to remember is that the DNS DKIM selectors WILL and 650 SHOULD be changed over time. Some reasons for changing DKIM 651 selectors are well understood, while others are still theoretical. 652 There are several schemes that may be used to determine the policies 653 for changing DKIM selectors: 655 o time based 657 o associations with clusters of servers 659 o the use of third party signers 661 o security considerations 663 4.1.1. Time Basis and Security Considerations 665 The reason for changing the selector periodically is usually related 666 to the security exposure of a system. When the potential exposure of 667 the private keys associated with the DKIM selector have reached 668 sufficient levels, the selector should be changed. (It is unclear 669 currently what kinds of metrics can be used to aid in deciding when 670 the exposure has reached sufficient levels to warrant changing the 671 selector.) 673 For example, 675 o Selectors should be changed more frequently on systems that are 676 widely exposed, than on systems that are less widely exposed. For 677 example, a gateway system that has numerous externally-accessible 678 services running on it, is more widely exposed than one that ONLY 679 runs a mail server. 681 o Selectors should be changed more frequently on operating systems 682 that are under wide attack. 684 o While the use of DKIM information is transient, keys with 685 sufficient exposure do become stale and should be changed. 687 o Whenever you make a substantial system change, such as bringing up 688 a new server, or making a major operating system change, you 689 should consider changing the selector. 691 o Whenever there is either suspicion or evidence of the compromise 692 of the system or the private keys, you should change the selector. 694 4.1.2. Deploying New Selectors 696 A primary consideration in changing the selector is remembering to 697 change it. It needs to be a standard part of the operational staff 698 Methods and Procedures for your systems. If they are separate, both 699 the mail team and the DNS team will be involved in deploying new 700 selectors. 702 When deploying a new selector, it needs to be phased in: 704 1. Generate the new public / private key pair and create a new 705 selector record with the public key in it. 707 2. Add the new selector record to your DNS. 709 3. Verify that the new selector record can be used to verify 710 signatures. 712 4. Turn on signing with the new private key. 714 5. Remove the old private key from your servers. 716 6. After a period of time, remove the old selector from your DNS. 718 The time an unused selector should be kept in the DNS system is 719 dependent on the reason it's being changed. If the private key has 720 definitely been exposed, the corresponding selector should be removed 721 immediately. Otherwise, longer periods are allowable. 723 4.1.3. Subdomain Considerations 725 A Domain Name is the basis for making differential quality 726 assessments about a DKIM-signed message. It is reasonable for a 727 single organization to have a variety of very different activities, 728 which warrant a variety of very different assessments. A convenient 729 way to distinguish among such activities is to sign with different 730 domain names. That is, the organization should sign with sub-domain 731 names that are used for different organizational activities. 733 4.1.4. Delegating Signing Authority to a Third party 735 Allowing third parties to sign email from your domain opens your 736 system security to include the security of the third party's systems. 737 At a minimum, you should not allow the third parties to use the same 738 selector and private key as your main mail system. It is recommended 739 that each third party be given their own private key and selector. 740 This limits the exposure for any given private key, and minimizes the 741 impact if any given private key were exposed. 743 4.2. Private Key Management 745 The permissions of private key files must be carefully managed. If 746 key management hardware support is available, it should be used. 747 Auditing software should be used to periodically verify that the 748 permissions on the private key files remain secure. 750 5. Example Uses 752 A DKIM signature tells the signature verifier that the owner of a 753 particular domain name accepts responsibility for the message. 754 Combining this information with information that allows the history 755 of the domain name owner to be assessed may allow processing the 756 message, based on the probability that the message is likely to be 757 trustworthy, or not, without the need for heuristic content analysis. 759 5.1. Protection of Internal Mail 761 One identity is particularly amenable to easy and accurate 762 assessment: The organization's own identity. Members of an 763 organization tend to trust messages that purport to be from within 764 that organization. However Internet Mail does not provide a 765 straightforward means of determining whether such mail is, in fact, 766 from within the organization. DKIM can be used to remedy this 767 exposure. If the organization signs all of its mail, then its 768 boundary MTAs can look for mail purporting to be from the 769 organization but does not contain a verifiable signature. Such mail 770 can be presumed to be spurious. 772 WHAT ABOUT MAIL TO A MAILING LIST THAT COMES BACK WITH A BROKEN 773 SIGNATURE???? 775 5.2. Recipient-based Assessments 777 Recipients of large volumes of email can internally generate 778 reputation data for email senders. Recipients of smaller volumes of 779 messages are likely to need to acquire reputation data from a third 780 party. In either case the use of reputation data is intrinsically 781 limited to email senders that have established a prior history of 782 sending messages. 784 In fact, an email receiving service may be in a position to establish 785 bilateral agreements with particular senders, such as business 786 partners or trusted bulk sending services. Although it is not 787 practical for each recipient to accredit every sender, the definition 788 of core networks of explicit trust can be quite useful. 790 5.2.1. Third-party Reputation and Accreditation Services 792 For scaling efficiency, it is appealing to use Trusted Third Party 793 reputation and accreditation services, to allow an email sender to 794 obtain a single assessment that is then recognized by every email 795 recipient that recognizes the Trusted Third Party. 797 5.3. DKIM Support in the Client 799 The DKIM specification is expected to be used primarily between 800 Boundary MTAs, or other infrastructure components of the originating 801 and receiving ADMDs. However there is nothing in DKIM that is 802 specific to those venues. In particular, it should be possible to 803 support signing and verifying in MUAs. 805 DKIM requires that all verifiers treat messages with signatures that 806 do not verify as if they are unsigned. If verification in the client 807 is to be acceptable to users, it is also essential that successful 808 verification of a signature not result in a less than satisfactory 809 user experience compared to leaving the message unsigned. 811 5.4. Per user signatures 813 Although DKIM's use of domain names is optimized for a scope of 814 organization-level signing, it is possible to administer sub-domains 815 and/or selectors in a way that supports per-user signing. 817 NOTE: As stated earlier, it is important to distinguish between the 818 use of selectors for differential administration of keys, versus 819 the use of sub-domains for differential reputations. 821 As a constraint on an authorized DKIM signing agent, their associated 822 key record can specify restrictions on the email addresses permitted 823 to be signed with that domain and key. A typical intent of this 824 feature is to allow a company to delegate the signing authority for 825 bulk marketing communications without the risk of effectively 826 delegating the authority to sign messages purporting to come from the 827 domain-owning organization's CEO. 829 NOTE: Any scheme that involves maintenance of a significant number 830 of public keys is likely to require infrastructure enhancements, 831 to support that management. For example, a system in which the 832 end user is required to generate a public key pair and transmit it 833 to the DNS administrator out of band is not likely to meet 834 acceptance criteria for either usability or security. 836 6. Security Considerations 838 TBD 840 7. IANA Considerations 842 TBD 844 8. Acknowledgements 846 TBD 848 9. Informative References 850 [I-D.ietf-openpgp-rfc2440bis] 851 Callas, J., "OpenPGP Message Format", 852 draft-ietf-openpgp-rfc2440bis-22 (work in progress), 853 April 2007. 855 [I-D.kucherawy-sender-auth-header] 856 Kucherawy, M., "Message Header Field for Indicating 857 Message Authentication Status", 858 draft-kucherawy-sender-auth-header-11 (work in progress), 859 February 2008. 861 [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement 862 for Internet electronic mail: Part I: Message encipherment 863 and authentication procedures", RFC 989, February 1987. 865 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 866 STD 13, RFC 1034, November 1987. 868 [RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME 869 Object Security Services", RFC 1848, October 1995. 871 [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message 872 Exchange Formats", RFC 1991, August 1996. 874 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 875 "OpenPGP Message Format", RFC 2440, November 1998. 877 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 878 April 2001. 880 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 881 April 2001. 883 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 884 "MIME Security with OpenPGP", RFC 3156, August 2001. 886 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, 887 August 2001. 889 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 890 Extensions (S/MIME) Version 3.1 Message Specification", 891 RFC 3851, July 2004. 893 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys 894 Identified Mail (DKIM)", RFC 4686, September 2006. 896 [RFC4870] Delany, M., "Domain-Based Email Authentication Using 897 Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, 898 May 2007. 900 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 901 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 902 Signatures", RFC 4871, May 2007. 904 Authors' Addresses 906 Tony Hansen 907 AT&T Laboratories 908 200 Laurel Ave. 909 Middletown, NJ 07748 910 USA 912 Email: tony+dkimov@maillennium.att.com 914 Phillip Hallam-Baker 915 VeriSign Inc. 917 Email: pbaker@verisign.com 919 Dave Crocker 920 Brandenburg InternetWorking 921 675 Spruce Dr. 922 Sunnyvale, CA 94086 923 USA 925 Email: dcrocker@bbiw.net 927 Full Copyright Statement 929 Copyright (C) The IETF Trust (2008). 931 This document is subject to the rights, licenses and restrictions 932 contained in BCP 78, and except as set forth therein, the authors 933 retain all their rights. 935 This document and the information contained herein are provided on an 936 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 937 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 938 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 939 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 940 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 941 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 943 Intellectual Property 945 The IETF takes no position regarding the validity or scope of any 946 Intellectual Property Rights or other rights that might be claimed to 947 pertain to the implementation or use of the technology described in 948 this document or the extent to which any license under such rights 949 might or might not be available; nor does it represent that it has 950 made any independent effort to identify any such rights. Information 951 on the procedures with respect to rights in RFC documents can be 952 found in BCP 78 and BCP 79. 954 Copies of IPR disclosures made to the IETF Secretariat and any 955 assurances of licenses to be made available, or the result of an 956 attempt made to obtain a general license or permission for the use of 957 such proprietary rights by implementers or users of this 958 specification can be obtained from the IETF on-line IPR repository at 959 http://www.ietf.org/ipr. 961 The IETF invites any interested party to bring to its attention any 962 copyrights, patents or patent applications, or other proprietary 963 rights that may cover technology that may be required to implement 964 this standard. Please address the information to the IETF at 965 ietf-ipr@ietf.org. 967 Acknowledgment 969 Funding for the RFC Editor function is provided by the IETF 970 Administrative Support Activity (IASA).