idnits 2.17.1 draft-ietf-dkim-overview-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1296. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1286. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([I-D.ietf-dkim-base]), 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 411: '... DKIM the signer MUST explicitly list ...' RFC 2119 keyword, line 919: '... o The verifier MAY change the degree...' RFC 2119 keyword, line 924: '... A. A verifier MAY chose to evaluate...' RFC 2119 keyword, line 928: '... o The verifier MAY make a determinat...' RFC 2119 keyword, line 936: '... o The verifier MAY decide to add sup...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 18, 2006) is 6519 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'LOGOTYPE' is mentioned on line 1035, but not defined == Missing Reference: 'PHB-NIST' is mentioned on line 1037, but not defined == Unused Reference: 'I-D.ietf-dkim-threats' is defined on line 1216, but no explicit reference was found in the text == Unused Reference: 'RFC0821' is defined on line 1221, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-dkim-base-02 -- Obsolete informational reference (is this intentional?): RFC 821 (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- 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 2822 (Obsoleted by RFC 5322) Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Hansen, Ed. 3 Internet-Draft AT&T Laboratories 4 Expires: December 20, 2006 D. Crocker 5 Brandenburg InternetWorking 6 P. Hallam-Baker 7 VeriSign Inc. 8 June 18, 2006 10 DomainKeys Identified Mail Overview 11 draft-ietf-dkim-overview-00.txt 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 December 20, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 DomainKeys Identified Mail DKIM [I-D.ietf-dkim-base] defines a 45 domain-level authentication framework for email using public-key 46 cryptography and key server technology to permit verification of the 47 source and contents of messages by either Mail Transfer Agents (MTAs) 48 or Mail User Agents (MUAs). The ultimate goal of this framework is 49 to permit a signing domain to assert responsibility for a message, 50 thus proving and protecting message sender identity and the integrity 51 of the messages they convey while retaining the functionality of 52 Internet email as it is known today. Proof and protection of email 53 identity, including repudiation and non-repudiation, may assist in 54 the global control of "spam" and "phishing". 56 This document provides an overview of DomainKeys Identified Mail and 57 how it can fit into overall messaging systems, how it relates to 58 other IETF message signature technologies, implementation and 59 migration considerations, and outlines potential DKIM applications 60 and future extensions. 62 Note 64 This document is being discussed on the DKIM mailing list, 65 ietf-dkim@mipassoc.org. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 1.1. About This Document . . . . . . . . . . . . . . . . . . . 5 71 1.2. A Quick Overview of DKIM . . . . . . . . . . . . . . . . . 5 72 1.2.1. Axiom: Ubiquitous Authentication is Good . . . . . . . 5 73 1.2.2. What is the purpose of DKIM? . . . . . . . . . . . . . 6 74 1.2.3. What does DKIM do? . . . . . . . . . . . . . . . . . . 7 75 1.2.4. Who validates the signature? . . . . . . . . . . . . . 7 76 1.2.5. What does DKIM *not* do? . . . . . . . . . . . . . . . 7 77 1.3. Outline Potential DKIM Applications . . . . . . . . . . . 8 78 2. DKIM Within Existing Internet Email . . . . . . . . . . . . . 8 79 2.1. Where to Place DKIM Functions . . . . . . . . . . . . . . 8 80 2.2. Impact on Email Activities . . . . . . . . . . . . . . . . 8 81 2.2.1. Resources . . . . . . . . . . . . . . . . . . . . . . 8 82 2.2.2. Operations . . . . . . . . . . . . . . . . . . . . . . 9 83 2.2.3. Users . . . . . . . . . . . . . . . . . . . . . . . . 9 84 2.3. Migrating from DomainKeys . . . . . . . . . . . . . . . . 9 85 2.3.1. Signing . . . . . . . . . . . . . . . . . . . . . . . 9 86 2.3.2. Verifying . . . . . . . . . . . . . . . . . . . . . . 10 87 2.4. { Misc Text -- Should go elsewhere, if used at all } . . . 10 88 3. Relationship to previous Message Signature Technologies . . . 11 89 3.1. Transparent Signature . . . . . . . . . . . . . . . . . . 11 90 3.2. Treat verification failure as if unsigned. . . . . . . . . 12 91 3.3. Legacy Client Semantics . . . . . . . . . . . . . . . . . 13 92 3.4. Key Centric PKI . . . . . . . . . . . . . . . . . . . . . 13 93 3.5. Domain Level Assurance . . . . . . . . . . . . . . . . . . 15 94 3.6. Security Policy . . . . . . . . . . . . . . . . . . . . . 15 95 4. Implementation Considerations . . . . . . . . . . . . . . . . 16 96 4.1. Development . . . . . . . . . . . . . . . . . . . . . . . 16 97 4.1.1. Signer . . . . . . . . . . . . . . . . . . . . . . . . 16 98 4.1.2. Validator . . . . . . . . . . . . . . . . . . . . . . 16 99 4.1.3. Outbound mail user agent . . . . . . . . . . . . . . . 16 100 4.1.4. Outbound mail transport agent . . . . . . . . . . . . 16 101 4.1.5. DNS Server . . . . . . . . . . . . . . . . . . . . . . 16 102 4.1.6. Mailing list manager . . . . . . . . . . . . . . . . . 16 103 4.1.7. Inbound mail transport agent . . . . . . . . . . . . . 16 104 4.1.8. Inbound mail user agent . . . . . . . . . . . . . . . 17 105 4.1.9. Accreditation service . . . . . . . . . . . . . . . . 17 106 4.2. Deployment . . . . . . . . . . . . . . . . . . . . . . . . 17 107 4.2.1. Signing . . . . . . . . . . . . . . . . . . . . . . . 17 108 4.2.2. Verifying . . . . . . . . . . . . . . . . . . . . . . 17 109 4.3. Operations . . . . . . . . . . . . . . . . . . . . . . . . 17 110 4.3.1. DNS Signature Record Deployment Considerations . . . . 17 111 4.3.2. Thoughts on Expiring Signatures . . . . . . . . . . . 17 112 4.3.3. DNS Policy Record Deployment Considerations . . . . . 18 113 4.3.4. Subdomain Considerations . . . . . . . . . . . . . . . 18 114 4.3.5. Third party Signature Delegations . . . . . . . . . . 18 116 5. Outline Future Extensions . . . . . . . . . . . . . . . . . . 18 117 5.1. Introducing a new signing algorithm . . . . . . . . . . . 19 118 5.2. Possible future signature algorithm choices . . . . . . . 19 119 5.3. Transition strategy . . . . . . . . . . . . . . . . . . . 20 120 5.3.1. Signer transition strategy . . . . . . . . . . . . . . 20 121 5.3.2. Verifier transition strategy . . . . . . . . . . . . . 21 122 5.4. Linkage to Other PKIs . . . . . . . . . . . . . . . . . . 21 123 5.5. Trusted Third Party Assertions . . . . . . . . . . . . . . 22 124 5.6. Linkage to X.509 Certificates . . . . . . . . . . . . . . 23 125 5.7. XKMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 126 5.8. Verification in the Client . . . . . . . . . . . . . . . . 24 127 5.9. Per user signature . . . . . . . . . . . . . . . . . . . . 25 128 5.10. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 25 129 5.11. Reuse of Key Record . . . . . . . . . . . . . . . . . . . 26 130 5.12. Use of Policy Record . . . . . . . . . . . . . . . . . . . 26 131 6. What Needs To Be Moved Here From the Base Doc? . . . . . . . . 27 132 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 133 8. Informative References . . . . . . . . . . . . . . . . . . . . 27 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 135 Intellectual Property and Copyright Statements . . . . . . . . . . 30 137 1. Introduction 139 1.1. About This Document 141 This document provides an overview of DomainKeys Identified Mail 142 (DKIM). It provides information for: those who are adopting DKIM; 143 those who are developing DKIMd;, those who are deploying DKIM; and 144 those who are considering extending DKIM, either into other areas or 145 to provide additional features. 147 This document does not provide information on threats to DKIM or 148 email, or details on the implementation. Such information can be 149 found in other RFC documents.[I-D.ietf-dkim-base] [I-D.ietf-dkim- 150 threats] Nor does this document describe how to solve the world's 151 problems with spam, phish, virii, worms, joe jobs, etc. 153 [ NOTE: a number of sections in this document are just placeholders 154 for now ] 156 1.2. A Quick Overview of DKIM 158 1.2.1. Axiom: Ubiquitous Authentication is Good 160 DKIM builds on previous work in the form of Domain Keys, Identified 161 Internet Mail, Authenticated Sender, Meta-Mail, etc. The starting 162 point for all of these technologies, and now DKIM, is the belief that 163 authenticating email is a good thing to do in and of itself. It has 164 been pointed out that it is unlikely that RFC 822 [RFC0822] would 165 pass today without some form of strong authentication mechanism. 166 DKIM provides such a strong authentication mechanism. 168 The ultimate goal of DKIM is to achieve a situation where email 169 authentication is ubiquitous and the unsigned email becomes the 170 exception the rule, as is the case today. Only when the majority of 171 Internet email is authenticated is it possible to make interesting 172 conclusions about the lack of authentication. 174 It follows then that a new message signature scheme is required to 175 meet the goal of ubiquitous authentication. In each of the above- 176 mentioned proposals, several design elements are shared: 178 The signature is carried in the message header and does not affect 179 the message body. 181 The signature may include certain headers. 183 There is a policy mechanism, either explicit or implicit, that 184 tells receivers when to expect a signature. 186 Keys are self-created (it is not necessary to buy a certificate). 188 Keys are stored in the DNS (it is not necessary to deploy a 189 separate key server). 191 The remarkable similarity of these architectural proposals strongly 192 suggests that this architecture should be the basis for unbiquitous 193 authentication. DKIM was produced by merging the two previous 194 proposals of DomainKeys and Identified Internet Mail. Significant 195 enhancements were then made from that base. 197 The approach taken by DKIM differs from previous approaches to 198 message signing in that: 200 the message signature is written as a message header field so that 201 neither human recipients nor existing MUA (Mail User Agent) 202 software are confused by signature-related content appearing in 203 the message body, 205 there is no dependency on public and private key pairs being 206 issued by well-known, trusted certificate authorities, 208 there is no dependency on the deployment of any new Internet 209 protocols or services for public key distribution or revocation, 211 it makes no attempt to include encryption as part of the 212 mechanism. 214 1.2.2. What is the purpose of DKIM? 216 DKIM lets an organization take responsibility for a message. The 217 organization taking responsibility is a handler of the message, 218 either as its originator or as an intermediary. Their reputation is 219 the basis for evaluating whether to trust the message for delivery. 221 The owner of the domain name being used for a DKIM signature is 222 declaring that they are accountable for the message. This means that 223 their reputation is at stake. 225 By design, DKIM purposely: 227 is compatible with the existing email infrastructure and 228 transparent to the fullest extent possible 230 requires minimal new infrastructure 232 can be implemented independently of clients in order to reduce 233 deployment time 234 does not require the use of trusted third parties (e.g., 235 certificate authoritys) which might impose significant costs or 236 introduce delays to deployment 238 can be deployed incrementally 240 allows delegation of signing to third parties 242 is not intended be used for archival purposes 244 DKIM authentication provides one link in a chain of responsibility, 245 hopefully leading to better accountability by the senders. 247 1.2.3. What does DKIM do? 249 DKIM defines a mechanism by which email messages can be 250 cryptographically signed, permitting a signing domain to claim 251 responsibility for the introduction of a message into the mail 252 stream. The responsible organization adds a digital signature to the 253 message, associating it with a domain name of that organization. 254 Typically, signing will be done by an service agent within the 255 authority of the message originator's Administrative Management 256 Domain (ADMD). (Signing might be performed by any of the functional 257 components in that environment, including a Mail User Agent (MUA), a 258 Mail Submission Agent (MSA), or an Internet Boundary MTA. DKIM also 259 permits signing to be performed by authorized third-parties.) 261 1.2.4. Who validates the signature? 263 After a message has been signed, any agent in the message transit 264 path can choose to validate the signature. Message recipients can 265 verify the signature by querying the signer's domain directly to 266 retrieve the appropriate public key, and thereby confirm that the 267 message was attested to by a party in possession of the private key 268 for the signing domain. Typically, validation will be done by an 269 agent in the ADMD of the message recipient. Again, this may be done 270 by any functional component within that environment. (Notably this 271 means that the signature can be used by the recipient ADMD's 272 filtering software, rather than requiring the recipient end-user to 273 make an assessment.) 275 1.2.5. What does DKIM *not* do? 277 DKIM does not: 279 o offer any assertions about the behaviors of the identity doing the 280 signing. 282 o prescribe any specific actions for receivers to take upon 283 successful (or unsuccessful) signature validation. 285 o provide protection after message delivery. 287 o protect against re-sending (replay of) a message that already has 288 a valid signature; therefore a transit intermediary or a recipient 289 can re-post the message in such a way that the signature would 290 remain valid, although the new recipient(s) would not have been 291 specified by the originator. 293 1.3. Outline Potential DKIM Applications 295 TBD 297 2. DKIM Within Existing Internet Email 299 Email service architecture review. 301 AdMD to AdMD, not MTA to MTA. (AdMD not equal Domain Name.) 303 2.1. Where to Place DKIM Functions 305 DKIM may be run within any component of an AdMD, such as: 307 Outbound: MSA or boundary MTA. 309 Inbound: Boundary MTA or MDA. 311 {explain basis tradeoffs/reasons for choices: s/w availability, user- 312 vs-ops, admin control/ease...} 314 2.2. Impact on Email Activities 316 2.2.1. Resources 318 Although the cryptographic authentication are considered to be 319 computationally expensive, the real impact of a mechanism, like DKIM, 320 is remarkably small. Direct impact on CPU-load has been measured to 321 be 10-15%. Usually, email is i/o-intensive, with unused 322 computational capacity. So, it is likely that no new hardware will 323 be required. 325 2.2.2. Operations 327 Administrative cost to deploy, versus expected reduction in the cost 328 of administration for problem email. 330 Challenge of mobile users. Server-resident folders -- web or imap -- 331 no problem. Laptop-resident folders, requires remote MSA access or 332 per-user keying and mobile-author awareness. 334 Key creation and replacement. Update DNS and signing component 336 2.2.3. Users 338 Challenge of mobile users. Server-resident folders -- web or imap -- 339 no problem. Laptop-resident folders, requires remote MSA access or 340 per-user keying and mobile-author awareness. 342 Challenge of mailing lists. Different list styles warrant different 343 signature policies. 345 Can be hidden from end-user; used by filter engine. Method and 346 benefits for displaying to users unknown. 348 2.3. Migrating from DomainKeys 350 2.3.1. Signing 352 2.3.1.1. DNS Records 354 DKIM is upward compatible with existing DomainKeys (DK) DNS records, 355 so that a DKIM module does not automatically require additional DNS 356 administration! DKIM has enhanced the DK DNS key record, to permit 357 the addition of several parameters. 359 2.3.1.2. Signing Module 361 DKIM uses a different RFC2822 [RFC2822] header field for storing the 362 signature, in order to distinguish it from DK. 364 DKIM includes language to make it clear which particular header field 365 is signed, if there is more than one header field of a given name in 366 the message. 368 DKIM allows some values that were scalars in DomainKeys to be colon- 369 separated arrays. For example, the list of query methods used to 370 find a key and the "t=" tags (originally testing, now flags). 372 DKIM permits copying the original version of headers fields and their 373 values, to aid in diagnosing signatures that do not survive transit. 375 DKIM has the ability to limit keys to hash algorithms specified in a 376 list, in the DNS record. 378 DKIM allows body length limits, to permit signatures, to survive 379 transit through some intermediaries, such as some mailing list agents 380 that add text to the end of the message. 382 2.3.1.3. Boundary MTA 384 Enforce signature policies and practises 386 2.3.2. Verifying 388 2.3.2.1. DNS Client 390 2.3.2.2. Verifying module 392 See "Signing Module". 394 2.3.2.3. Boundary MTA 396 Strip "local" signatures that are not local? 398 2.4. { Misc Text -- Should go elsewhere, if used at all } 400 DKIM permits the signing identity to be different from the identities 401 used for the author or the initial posting agent. This is essential, 402 for example, to enable support of signing by authorized third- 403 parties, and to permit signatures by email providers who are 404 otherwise independent of the domain name of the message author. 406 DKIM permits restricting the use of a signature key to particular 407 types of services, such as only for email. This is helpful when 408 delegating signing authority, such as to a particular department or 409 to a third-party outsourcing service. 411 With DKIM the signer MUST explicitly list the headers that are 412 signed. This is an improvement because it requires the signer to use 413 the more conservative (likely to verify correctly) mechanism and 414 makes it considerably more robust against the handling of 415 intermediary MTAs. 417 DKIM self-signs the DKIM-Signature header field, to protect against 418 its being modified. 420 In order to survive the vagaries of different email transfer systems, 421 mechanisms like DKIM must evaluate the message data in some canonical 422 form, such as treating a string of spaces as tabs as if they were a 423 single space. DKIM has added the "relaxed" canonicalization in place 424 of "nofws". 426 3. Relationship to previous Message Signature Technologies 428 DKIM is the fifth IETF proposal for an email signature scheme. The 429 first RFC describing Privacy Enhanced Mail (PEM) was published in 430 1987 [RFC0989]. The PEM scheme went through a number of revisions 431 and eventually transformed into MIME Object Security Services in 1995 432 [RFC1848]. 434 Neither PEM nor MOSS ever achieved significant deployment. PEM 435 relied on the prior deployment of an extensive PKI predicated on a 436 rigid hierarchy of Certificate Authorities. By the time it was 437 understood that this infrastructure assumption was unrealistic the 438 opportunity to deploy PEM had closed. 440 Pretty Good Privacy (PGP) was developed by Phil Zimmerman and 441 released in 1991 and quickly established a significant support base 442 within the security community. This support base was driven by two 443 principal factors: superior ease of deployment and an aggressive 444 marketing campaign assisted by the U.S. government. A working group 445 was formed within the IETF to continue development of the PGP 446 protocol as OpenPGP beginning with publication of the original 447 protocol as an informational RFC in 1996 [RFC1991]. 449 At the same time RSA Security, the holder of the patent rights to the 450 principle public key cryptography algorithm independently developed 451 Secure MIME (S/MIME) which employed the recently developed MIME 452 format to transport a PKCS #7 data object. S/MIME was particularly 453 attractive for software developers who had already implemented SSL as 454 much of the code required to support could be reused. 456 Development of S/MIME and OpenPGP has continued in the IETF since. 457 While both have achieved a significant user base neither has achieved 458 ubiquity. In particular it is notable that only a small percentage 459 of messages on the IETF mailing lists concerned with security are 460 signed. 462 3.1. Transparent Signature 464 The core goals of DKIM require that use of message signatures becomes 465 ubiquitous. For this to be possible it must be possible to apply a 466 signature to any message in any circumstance with a negligible chance 467 of causing a negative user experience for any recipient regardless of 468 the legacy email client used. 470 Experiences from S/MIME and PGP deployment strongly indicate that 471 this usability goal can only be met if the addition of the signature 472 leaves the message body unchanged. 474 S/MIME and PGP are both designed to achieve the highest level of 475 security possible. The sender of a message is assured that the 476 confidentiality and/or integrity of the message are protected from 477 the originating end point machine to the destination end point. 479 Achieving this level of security naturally places requirements on 480 both the sender and the receiver. Support for both signature and 481 encryption causes a subtle but important architectural assumption to 482 be introduced. Although signature and encryption are complimentary 483 from a cryptographic point of view their effect is entirely different 484 from a messaging protocol point of view. A digital signature is 485 meta-data providing information about the message contents. 486 Encryption is a transformation of the message content (and possibly 487 related meta-data). 489 The recipient of an encrypted email message must as a matter of 490 course have a specially adapted email client capable of decrypting 491 the message. Adding a signature to the message does not in principle 492 create a requirement for the recipient to have a specially adapted 493 client provided the signature is added in a manner that is ignored by 494 legacy clients. 496 In the case of an S/MIME signature the recipient is at a minimum 497 expected to have a client capable of decoding the MIME multipart/ 498 security format. In practice this means that the recipient must 499 support S/MIME. OpenPGP allows the use of a signature encapsulation 500 that is not MIME based. This has the advantage that the message can 501 be read using a standard email client. The disadvantage with this 502 approach is that the application of the signature is visible to the 503 user and thus intrusive. 505 3.2. Treat verification failure as if unsigned. 507 PGP and S/MIME were both designed to meet a high standard of 508 cryptographic excellence. At the time the protocols were designed it 509 was generally considered that the correct thing for an application to 510 do in the case of a signature verification failure was to warn the 511 user that the message was unsigned. In a small number of cases the 512 application went even further 'warning' the user whenever a signed 513 message was received. 515 This type of user experience has since been severely deprecated. A 516 user who is constantly bombarded with warning messages is much less 517 likely to respond appropriately when an important warning message is 518 received. 520 While modern messaging infrastructure is considerably friendlier to 521 the use of digital signatures than in the past even a residual 522 failure rate of 1% results in unacceptably high support costs when 523 signatures are used ubiquitously. 525 It is now generally accepted that the correct semantics for an email 526 signature verifier to adopt are to treat messages with signatures 527 that fail as if they are unsigned. 529 It is highly unlikely that an attacker is going to add a digital 530 signature to a message unless doing so causes the message to be 531 treated more favorably than an unsigned one. Any messages that carry 532 signatures that fail verification are thus much more likely to be a 533 genuine message that has been damaged in transit than an attempted 534 forgery. It makes no sense to warn the recipient unless it is known 535 that the sender always signs email messages and that there is a high 536 probability that a forgery would be attempted. 538 3.3. Legacy Client Semantics 540 The deployed base of S/MIME is both a benefit and a burden. While 541 the S/MIME protocol is in principle capable of extension to support 542 many of the features of DKIM, the same is not true of the deployed 543 S/MIME base. 545 While the S/MIME protocol can in principle support semantics such as 546 domain level signatures or make use of keys stored in the DNS the 547 legacy deployed base does not. The behavior of legacy clients 548 receiving an S/MIME message dependent on the novel semantics is 549 likely to result in a negative user experience in a significant 550 number of cases. 552 3.4. Key Centric PKI 554 Unlike all four previous IETF email security initiatives, DKIM 555 employs a key centric, directory based PKI as opposed to a 556 certificate based PKI in the style of Kohnfelder (X.509) or Zimmerman 557 (web of trust). 559 While message syntax and PKI are orthogonal in principle, 560 implementation practice means that most S/MIME clients only support 561 use of keys contained in X.509/PKIX digital certificates. 563 Although PGP is sometimes held up as an alternative to a certificate 564 based PKI a PGP key signing is in essence a digital certificate by 565 another name. There has since been considerable conversion as X.509 566 has adopted the web of trust principle under the term cross- 567 certification. The chief distinction between the PGP and PKIX models 568 is that in the PGP model every user is also (potentially) a trust 569 provider. In PKIX trust providers are distinct from end-entities. 571 The Kohnfelder architecture was originally designed to allow use of 572 public key cryptography before the ubiquitous availability of 573 networking. A particular benefit of the Kohnfelder architecture is 574 that Alice can send an encrypted message to Bob when the only 575 transport available is sending floppy disks through the postal 576 system. Another benefit of the Kohnfelder architecture is that a 577 signed message supported by a digital certificate is self supporting 578 and may be verified years after the fact provided only that the CA 579 signing key does not become compromised. 581 The principle weakness in PKIs based on the Kohnfelder architecture 582 is the difficulty of locating the correct digital key in the absence 583 of a directory infrastructure. This led Brian LaMacchia, then at MIT 584 to develop the MIT PGP key server, in effect returning to the 585 original public key directory model proposed by Whitt Diffe and Marty 586 Hellman. 588 XML Key Management Service (XKMS) realizes the key centric PKI model 589 as a SOAP based Web Service. In the XKMS model the PKI client makes 590 a request of the form 'provide me with the signing key that Alice 591 uses with the PGP protocol'. 593 Although DKIM follows the same architectural model as XKMS, DNS is 594 used as the transport layer in place of SOAP over HTTP. 596 The use of DNS significantly reduces the infrastructure requirements 597 for DKIM as existing DNS servers are used for key distribution. This 598 approach also has significant performance advantages as DNS is layers 599 on UDP and key retrieval is typically achieved in a single round 600 trip. XKMS requires a TCP session to be established and the request 601 and response messages are significantly larger. 603 The principle disadvantage of using DNS over XKMS is that the DNS is 604 a network administration resource designed to answer questions about 605 current network configuration. While it is quite possible to re-use 606 the DNS infrastructure to support queries about past and even future 607 network configurations this is not the core objective of the 608 infrastructure. The DNS is thus unsuited to supporting any use of 609 digital signatures in which long term archival is desirable or the 610 possibility of repudiation is undesirable. 612 3.5. Domain Level Assurance 614 As previously mentioned PGP and S/MIME were designed in the heyday of 615 the security end-to-end principle. It has since been realized that 616 the end points with respect to trust are not the same as the end 617 points with respect to the communication protocol. 619 When Alice sends a personal message to Bob it is Alice the person, 620 not the machine Alice happens to be using that is the true trust end 621 point. When Alice sends a piece of business correspondence to Bob it 622 is her employer. 624 The objective of DKIM is to allow parties to accept responsibility 625 for messages by signing them. While accepting responsibility at the 626 personal level may be desirable in some circumstances the Internet 627 now has a billion users. Attempting to achieve accountability in a 628 population of a billion users is impractical, particularly when the 629 owner of the domain example.com has the ability to create a 630 practically unlimited number of accounts within that domain at will. 632 The logical unit of accountability for DKIM is therefore the DNS 633 domain name to which the signing key record is bound and not the 634 individual email user. 636 3.6. Security Policy 638 The innovation in DKIM that has no precedent in the previous email 639 security standards is the publication of a security policy. The 640 purpose of DKIM is to allow a party to accept responsibility for an 641 email message by signing it. A message with a signature is treated 642 as if it is unsigned. For a recipient to interpret an unsigned 643 message it is necessary to know whether it should expect a message 644 from that source to be signed and if so the signature characteristics 645 to expect. 647 The introduction of security policy allows unsigned messages and 648 messages that fail signature validation to be subjected to a higher 649 level of anti-spam filtering or rejected out of hand in circumstances 650 where the owner of the purported originating domain suggests. For 651 example a bank concerned at the possibility of phishing attack might 652 publish a policy stating that all legitimate messages from the domain 653 are signed. 655 While the Sender-ID/SPF security policy format allows application to 656 existing formats including PGP and S/MIME the advantages to 657 developing the protocol and security policy in tandem are 658 considerable. It is not practical to expect to be able to write a 659 useful sender signing policy for S/MIME or PGP within the constraints 660 of the 512 byte response message size imposed on the legacy DNS. 662 4. Implementation Considerations 664 4.1. Development 666 What software has to change, to use DKIM? 668 4.1.1. Signer 670 The signer needs to add code in the appropriate agent, to perform 671 signing, and they need to modify their DNS administrative tools to 672 permit creation of DKIM key records. 674 4.1.2. Validator 676 A validator needs to add code to the appropriate agent and then feed 677 the result into the portion of their system needing it, such as a 678 filtering engine. 680 The mere existence of a valid signature does not imply that the mail 681 is acceptable, such as for delivery. Acceptability requires an 682 assessment phase. Hence the result of signature validation must be 683 fed into a vetting mechanism that is part of the validator's filter. 685 4.1.3. Outbound mail user agent 687 TBD 689 4.1.4. Outbound mail transport agent 691 TBD 693 4.1.5. DNS Server 695 TBD 697 4.1.6. Mailing list manager 699 TBD 701 4.1.7. Inbound mail transport agent 703 TBD 705 4.1.8. Inbound mail user agent 707 TBD 709 4.1.9. Accreditation service 711 TBD 713 4.2. Deployment 715 4.2.1. Signing 717 4.2.1.1. DNS Records 719 add sig key info 721 4.2.1.2. Signing Module 723 Delete old signs with same key; add new sig 725 4.2.1.3. Boundary MTA 727 Enforce signature policies and practises 729 4.2.2. Verifying 731 4.2.2.1. DNS Client 733 Ensure able to obtain DKIM key sig records 735 4.2.2.2. Verifying module 737 Validate sig; channel info to filtering engine. Maybe provide user- 738 visible info. 740 4.2.2.3. Boundary MTA 742 Strip "local" signatures that are not local? 744 4.3. Operations 746 4.3.1. DNS Signature Record Deployment Considerations 748 TBD 750 4.3.2. Thoughts on Expiring Signatures 752 TBD 754 4.3.3. DNS Policy Record Deployment Considerations 756 TBD 758 4.3.4. Subdomain Considerations 760 TBD 762 4.3.5. Third party Signature Delegations 764 TBD 766 5. Outline Future Extensions 768 The design of DKIM is unapologetically focused on overcoming the need 769 for immediate deployment and achieving ubiquitous use in the near 770 future. As such the original design discussions have generally taken 771 the approach 'if in doubt leave it out'. 773 The need to exclude consideration of these features in the near term 774 is in no way intended to preclude their development at a later date. 775 Nor is the lack of a specification describing the use of DKIM with a 776 different PKI infrastructure intended to indicate an intention to 777 develop similar capabilities within the DKIM framework at a future 778 date. 780 DKIM is an example of 'Design for Deployment'. The need to support 781 rapid deployment is the overriding priority. It has traditionally 782 been asserted that deployment of a flawed cryptographic protocol is 783 an almost unacceptable risk, that bad security is worse than no 784 security. Experience demonstrates otherwise. Informing users that 785 email is insecure does not cause them to modify their behavior to 786 avoid dependence thereupon. Deployment of flawed cryptographic 787 security systems such as SSL and WEP has been rectified far more 788 quickly than deployment of protocols such as IPSEC or DNSSEC where 789 caution has prevailed. 791 One possible future for DKIM is that it becomes the starting point 792 for a new cryptographic infrastructure that eventually replaces 793 legacy systems including S/MIME and PGP. While this future is 794 certainly preferable to never achieving ubiquitous deployment of 795 strong cryptographic security in the Internet it would certainly take 796 a long time to re-invent this particular wheel. Moreover the 797 deployment of the proposed DKIM enhancements would face political 798 opposition from the adherents to existing formats to be rendered 799 historical. A likely outcome of such a strategy is that the existing 800 two way standards stalemate between S/MIME and PGP would become a 801 three way stalemate. 803 Another possible future is that DKIM provides the 'bootstrap' that 804 enables ubiquitous use of legacy infrastructure including the 805 deployed base of PGP and S/MIME capable email clients and the 806 existing business infrastructure of commercial Certificate 807 Authorities. Such a strategy would make use of DKIM in conjunction 808 with existing PKI standards such as PKIX and XKMS and leverage 809 features of PGP and S/MIME where appropriate. 811 5.1. Introducing a new signing algorithm 813 Regardless of whether extension of the DKIM feature set is desirable 814 the need to replace the signature algorithm is practically a 815 certainty. The RSA signature algorithm at best provides equivalent 816 security to an 80 bit symmetric cipher when used with a 1024 bit key 817 [cite]. Extending the key size to 2048 bits improves the cipher 818 strength to only 112 bit equivalence. Achieving 128 bit security 819 requires a minimum of 3072 bits. Achieving equivalent cipher 820 strength to a 192 bit symmetric algorithm requires a prohibitive key 821 size. 823 The choice of cryptographic algorithm affects the DKIM algorithm in 824 two important ways. First there is the difficulty of storing keys in 825 the DNS. Secondly there is the problem of handling larger 826 signatures. 828 The default DNS response packet limit of 512 bytes places an 829 effective upper bound of 4096 bits on a DKIM key. In practice the 830 need for packaging, meta-data and the desirability of using DNSSEC to 831 sign the record reduces the upper bound to no more than 2048 bits. 833 The size of the DKIM signature itself is a weaker constraint. Even 834 so, while 1024 and even 2048 bit signatures are likely to be 835 acceptable in most implementations larger signature sizes may become 836 prohibitive, particularly as the signature must be Base 64 encoded. 838 5.2. Possible future signature algorithm choices 840 ECC cryptography offers a means of implementing public key 841 cryptography using a key size and signature size that are each only 842 twice the size of the equivalent symmetric key algorithm. 844 While ECC offers clear technical advantages over algorithms based on 845 the difficulty on solving the discrete log problem in a finite field 846 it is not possible at this point to be confident that a means of 847 applying ECC that is consistent with the position on intellectual 848 property adopted by the DKIM working group has been found. 850 The DSA signature algorithm based on the discrete log problem faces 851 the same key size limitations as RSA. Importantly for the design of 852 DKIM and DNSSEC however the signature size is much smaller, the same 853 size as for ECC algorithms. 855 It is likely that DSA would have received greater attention during 856 the design of DSA if key sizes greater than 512 bits and use of hash 857 functions stronger than SHA-1 had been supported at the time. In 858 March 2006 a proposed revision of the DSA signature algorithm 859 answered these objections permitting larger key sizes and specifying 860 use of stronger hash functions including SHA-256 and SHA 512. While 861 the advantages offered by DSA are not sufficient to warrant an 862 immediate transition to the new algorithm at this late stage it is 863 highly probably that the algorithm will be employed by DNSSEC when 864 finally deployed. 866 5.3. Transition strategy 868 Deployment of a new signature algorithm without a 'flag day' requires 869 a transition strategy such that signers and verifiers can phase in 870 support for the new algorithm independently and if necessary phase 871 out support for the old algorithm independently. 873 DKIM achieves these requirements through two features. First a 874 signed message may contain multiple signatures created by the same 875 signer. Secondly the security policy layer allows the signing 876 algorithms in use to be advertised, thus preventing a downgrade 877 attack. 879 5.3.1. Signer transition strategy 881 Let the old signing algorithm be A, the new signing algorithm be B. 882 The sequence of events by which a Signer may introduce a new signing 883 algorithm without disruption of service to legacy verifiers is as 884 follows: 886 1. Signer signs with algorithm A 888 A. Signer advertises that it signs with algorithm A 890 2. Signer signs messages twice, first with algorithm A and algorithm 891 B 893 A. The signer tests new signing configuration 895 B. Signer advertises that it signs with algorithm A and 896 algorithm B 898 3. Signer determines that support for Algorithm A is no longer 899 necessary 901 4. Signer determines that support for algorithm A it to be withdrawn 903 A. Signer removes advertisement for Algorithm A 905 B. Signer waits for cached copies of earlier signature policy to 906 expire 908 C. Signer stops signing with Algorithm A 910 5.3.2. Verifier transition strategy 912 The actions of the verifier are independent of the signer's actions 913 and do not need to be performed in a particular sequence. The 914 verifier may make a decision to cease accepting algorithm A without 915 first deploying support for algorithm B. Similarly a verifier may be 916 upgraded to support algorithm B without requiring algorithm B to be 917 withdrawn. The decisions of the verifier must make are therefore: 919 o The verifier MAY change the degree of confidence associated with 920 any signature at any time, including determining that a given 921 signature algorithm provides a limited assurance of authenticity 922 at a given key strength. 924 A. A verifier MAY chose to evaluate signature records in any 925 order it chooses, including making use of the signature 926 algorithm for this purpose. 928 o The verifier MAY make a determination that Algorithm A does not 929 offer a useful level of security, that the cost of verifying the 930 signature is less than the value of doing so. 932 A. In this case the verifier ignores signatures created using the 933 algorithm A and references to algorithm A in policy records 934 are treated as if the algorithm is not implemented. 936 o The verifier MAY decide to add support for additional signature 937 algorithms at any time. 939 A. The verified MAY add support for algorithm B at any time. 941 5.4. Linkage to Other PKIs 943 The principle limitations in DKIM are the lack of support for end- 944 user keying, the lack of support for long term verification of 945 signatures and the lack of support for trusted third party issued 946 assertions. Each of these limitations is determined by the key 947 distribution mechanism rather than the signature format. 949 Although the DNS infrastructure could in principle be extended to 950 support these features this approach would require substantial 951 modifications that entirely negate the advantage of employing an 952 existing infrastructure. The point of using DNS is to reuse the DNS 953 infrastructure, not the DNS protocol. 955 The preferred approach to addressing these limitations is to support 956 use of a PKI infrastructure designed to support these requirements 957 such as PKIX, PGP or XKMS. 959 5.5. Trusted Third Party Assertions 961 A DKIM signature tells the signature verifier that the owner of a 962 particular domain name accepts responsibility for the message. 963 Combining this information with information that allows the behavior 964 of the domain name owner to be predicted may allow the probability 965 that the message is abusive to be determined without the need for 966 heuristic content analysis. 968 Recipients of large volumes of email can generate reputation data for 969 email senders internally. Recipients of smaller volumes of messages 970 are likely to need to acquire reputation data from a third party. In 971 either case the use of reputation data is intrinsically limited to 972 email sender which have established a prior history of sending 973 messages. 975 Another commonly used technique for evaluating email senders is 976 accreditation. Most spam sent today is sent by criminals to further 977 a scheme that is unambiguously illegal. Spam demonstrates an 978 Internet equivalent of Gresham's law: the bad spam drives out the 979 merely irritating, the outright criminal drives out the bad. A 980 message is highly unlikely to be spam if the email sender that can 981 demonstrate that it is a legitimate business and that it has provided 982 a legitimate address where legal process can be served. In addition 983 the accredited email sender may accept a legally binding undertaking 984 not to send spam and possibly post a performance bond that is subject 985 to forfeiture in case of default. 987 As with reputation data a high volume email recipient may be in a 988 position to establish bilateral agreements with high volume senders. 989 Smaller recipients are not in a position to require accreditation, 990 nor is it practical for each large sender to accredit every sender. 991 Trusted Third Party accreditation services allow an email sender to 992 obtain an accreditation that is recognized by every email recipient 993 that recognizes the Trusted Third Party. 995 [Need use of both systems] 997 [Need means of advertising existence of positive reputation data] 999 5.6. Linkage to X.509 Certificates 1001 The industry standard for distribution of Trusted Third Party data 1002 tied to a public key is the X.509v3/PKIX standard. X.509 based PKI 1003 is designed to support requirements such as long term archiving of 1004 signatures, end entity signing and Trusted Third Party assertions. 1005 Combining the DKIM signature format with the PKIX PKI infrastructure 1006 provides an equivalent set of capabilities to S/MIME. 1008 Two approaches may be used to inform signature verifiers that an 1009 X.509 certificate has been issued that makes an assertion about the 1010 signing key for a DKIM signature: 1012 1. By means of an attribute in the key record 1014 2. By means of a signature header q= parameter 1016 Typical commercially issued digital certificates are considerably 1017 larger (1-2 kb) than the 512 byte message size that DNS servers are 1018 required to support as a minimum. Practical large scale PKI 1019 deployment requires support for certificate chains in addition to the 1020 end entity certificate. Publication of a URL for the certificate or 1021 certificate chain is therefore a more appropriate approach than 1022 storing the certificate data itself in the DNS. 1024 The ability to support multiple key distribution mechanisms for the 1025 same key is highly desirable. For example a signer may support DNS 1026 based key distribution for the convenience and efficiency of 1027 transport based DKIM signature verifiers and an X.509 certificate 1029 In other cases a signer may intentionally discourage transport 1030 verification by only providing an X.509 certificate. 1032 An X.509 application of particular interest is the use of DKIM as a 1033 signature format for Secure Internet Letterhead (Letterhead). 1034 Letterhead employs X.509 certificates containing a LOGOTYPE attribute 1035 extension [LOGOTYPE] to identify the certificate subject and/or 1036 issuer to the user by means of a brand image such as a corporate 1037 logo. [PHB-NIST] 1039 5.7. XKMS 1041 XKMS is a key centric PKI that supports registration and location of 1042 keys. XKMS is layered as a Web service and the existence of XKMS 1043 service for a domain is typically advertised by means of a DNS SRV 1044 record. 1046 XKISS, the key location component of XKMS provides a superset of the 1047 capabilities of the DKIM DNS key distribution mechanism. As XKMS is 1048 layered on SOAP over HTTP over TCP/IP the overhead incurred in 1049 retrieving keys through XKMS is substantially higher than the single 1050 UDP request/response of DNS key distribution. 1052 Like X.509 XKMS is designed to key management over time periods of 1053 years and decades rather than days and supports the use of trusted 1054 third parties. XKMS is designed to allow complexity to be 1055 concentrated at the Web service as opposed to the client. A client 1056 interacts with an XKMS service using request of the form 'provide a 1057 key to verify signatures on messages sent by A using protocol B'. 1059 XKMS may also be used as a gateway to one or more PKIs including an 1060 X.509 based PKI that makes use of sophisticated features such as 1061 cross certification. The verifier may at its option rely on the XKMS 1062 service to provide a trusted key or request the complete certificate 1063 path allowing offline verification. 1065 A signer may notify signature verifiers that a key may be retrieved 1066 using XKMS by means of the q= attribute. The verifier may then 1067 discover the corresponding XKMS service using the SRV mechanism as 1068 setout in the XKMS specification. 1070 5.8. Verification in the Client 1072 The DKIM specification is designed to support edge to edge 1073 authentication. The specification neither supports nor prohibits 1074 verification of DKIM signatures in the client. In particular the 1075 specification does not attempt to define client semantics for 1076 signatures or provide an exhaustive list of user interface security 1077 considerations. 1079 For client based verification to be practical it is likely the a 1080 client needs to be capable of determining that it is able to receive 1081 messages that do not get clobbered before coming to any conclusions 1082 with respect to unsigned messages. 1084 DKIM requires that all verifiers treat messages with signatures that 1085 do not verify as if they are unsigned. If verification in the client 1086 is to be acceptable to users it is also essential that successful 1087 verification of a signature does not result in a less satisfactory 1088 user experience than leaving the message unsigned. 1090 5.9. Per user signature 1092 Although DKIM is designed to support domain level signatures the DKIM 1093 core design neither supports nor prohibits use of per user 1094 signatures. A DKIM key record can specify restrictions on the email 1095 addresses it can be used to sign for. These restrictions are not 1096 intended to be exhaustive nor are detailed semantics or security 1097 considerations set out for interpreting per user signatures. The 1098 primary use this feature is intended to support is to allow a company 1099 to delegate signing authority for bulk marketing communications 1100 without the risk of effectively delegating the authority to sign 1101 contracts on behalf of the CEO. 1103 For per user signing keys to provide value beyond this limited use 1104 scenario it is likely that additional requirements are necessary such 1105 as the ability to perform long term validation of the key. Linkage 1106 to some form of PKI is likely to be necessary. 1108 In addition any scheme that involves maintenance of a significant 1109 number of public keys will require infrastructure to support that 1110 management. A system in which the end user is required to generate a 1111 public key pair and transmit it to the DNS administrator out of band 1112 is not likely to meet acceptance criteria for either usability or 1113 security. As a minimum a key registration protocol must be defined. 1115 5.10. Encryption 1117 DKIM is not designed to support encryption. A strong case can be 1118 made for applying the DKIM style of transparent security, key centric 1119 key management and domain level keying. It is not clear that re- 1120 using the DKIM signature architecture is the best way to achieve this 1121 goal. 1123 The DKIM signature format in particular is designed to allow meta- 1124 data to be attached to a message without modifying the content. 1125 Content encryption by its very nature requires modification of the 1126 message content. The message encryption formats of PGP and S/MIME 1127 both solve the problem of message encryption perfectly adequately and 1128 there is no reason to believe that a new effort in this space would 1129 improve matters. 1131 An architecture of this form would require development of an email 1132 receiver security policy that allows a recipient to state that 1133 encrypted email messages are acceptable and to specify key 1134 distribution infrastructure(s) by which the necessary encryption keys 1135 may be discovered. 1137 A policy infrastructure of this type is implicit in the XKMS 1138 standard. One drawback to this approach is that policy distribution 1139 an key distribution are conflated, an approach hat is satisfactory 1140 for message level encryption schemes such as PGP and S/MIME but less 1141 satisfactory for transport layer encryption such as SSL. 1143 5.11. Reuse of Key Record 1145 A number of proposals have been made which attempt to reuse the DKIM 1146 key record. Architects considering this approach should be aware of 1147 the advantages and limitations. 1149 As a minimum each of the security considerations listed in the DKIM 1150 specification should be considered and its possible relevance to the 1151 proposed field of use carefully evaluated. Application of a security 1152 mechanism outside the context in which it was originally designed for 1153 is a principle cause of security failures. 1155 DKIM is designed to meet the security needs of an application where 1156 the cost of individual failures is insignificant or small. A single 1157 spam in an email inbox is not a disaster, indeed it is no longer even 1158 an irritation. For the long time spam sufferer who has seen their 1159 inbox filled with hundreds or even thousands of spams an occasional 1160 failure may even be cause for satisfaction, a reminder of a 1161 successfully vanquished foe. 1163 One of the chief limitations of using DNS based key records is that 1164 maintenance of DNS records is typically a network operations concern. 1165 If the entity to which the public key corresponds is a network object 1166 (e.g. a mail server) the use of DNS based key management is likely to 1167 be satisfactory. If the entity is not a network related object (e.g. 1168 an end user) a significant degree of pushback from network 1169 administrators should be anticipated. 1171 The design of DKIM is designed for rapid deployment in response to an 1172 immediate need. As such many of the design decisions are not the 1173 decisions that would be taken if the choice was unconstrained by the 1174 limitations of the current legacy DNS. In particular the use of Base 1175 64 encoded public keys distributed through TXT records is not ideal. 1177 Applications that do not face the same constraints as DKIM should 1178 carefully evaluate the feasibility of using the binary key record. 1179 In particular an application predicated on the use of DNSSEC to 1180 authenticate keys should assume support for DKIM binary key records. 1182 5.12. Use of Policy Record 1184 DKIM demonstrates the power of using the DNS to distribute security 1185 policy information. It is not possible to achieve robust security 1186 unless the parties to a conversation know the security capabilities 1187 and expectations of the other. 1189 Any party proposing re-use of the DKIM policy record should carefully 1190 consider whether their needs would be better met by proposing a 1191 flexible security policy architecture in the DKIM style rather than 1192 proposing ad-hoc extensions and variations. 1194 At a minimum any proposal for new security policy formats that make 1195 use of the TXT record should employ a new policy prefix and ensure 1196 that mislabeled and wild-carded policy records are not accidentally 1197 misinterpreted. 1199 6. What Needs To Be Moved Here From the Base Doc? 1201 MUA considerations 1203 key delegation/ 3rd party 1205 7. Acknowledgements 1207 TBD 1209 8. Informative References 1211 [I-D.ietf-dkim-base] 1212 Allman, E., "DomainKeys Identified Mail Signatures 1213 (DKIM)", draft-ietf-dkim-base-02 (work in progress), 1214 May 2006. 1216 [I-D.ietf-dkim-threats] 1217 Fenton, J., "Analysis of Threats Motivating DomainKeys 1218 Identified Mail (DKIM)", draft-ietf-dkim-threats-03 (work 1219 in progress), May 2006. 1221 [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, 1222 RFC 821, August 1982. 1224 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 1225 text messages", STD 11, RFC 822, August 1982. 1227 [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement 1228 for Internet electronic mail: Part I: Message encipherment 1229 and authentication procedures", RFC 989, February 1987. 1231 [RFC1848] Crocker, S., Galvin, J., Murphy, S., and N. Freed, "MIME 1232 Object Security Services", RFC 1848, October 1995. 1234 [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message 1235 Exchange Formats", RFC 1991, August 1996. 1237 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1238 April 2001. 1240 Authors' Addresses 1242 Tony Hansen (editor) 1243 AT&T Laboratories 1244 200 Laurel Ave. 1245 Middletown, NJ 07748 1246 USA 1248 Email: tony+dkimov@maillennium.att.com 1250 Dave Crocker 1251 Brandenburg InternetWorking 1252 675 Spruce Dr. 1253 Sunnyvale, CA 94086 1254 USA 1256 Email: dcrocker@bbiw.net 1258 Phillip Hallam-Baker 1259 VeriSign Inc. 1260 USA 1262 Email: pbaker@verisign.com 1264 Intellectual Property Statement 1266 The IETF takes no position regarding the validity or scope of any 1267 Intellectual Property Rights or other rights that might be claimed to 1268 pertain to the implementation or use of the technology described in 1269 this document or the extent to which any license under such rights 1270 might or might not be available; nor does it represent that it has 1271 made any independent effort to identify any such rights. Information 1272 on the procedures with respect to rights in RFC documents can be 1273 found in BCP 78 and BCP 79. 1275 Copies of IPR disclosures made to the IETF Secretariat and any 1276 assurances of licenses to be made available, or the result of an 1277 attempt made to obtain a general license or permission for the use of 1278 such proprietary rights by implementers or users of this 1279 specification can be obtained from the IETF on-line IPR repository at 1280 http://www.ietf.org/ipr. 1282 The IETF invites any interested party to bring to its attention any 1283 copyrights, patents or patent applications, or other proprietary 1284 rights that may cover technology that may be required to implement 1285 this standard. Please address the information to the IETF at 1286 ietf-ipr@ietf.org. 1288 Disclaimer of Validity 1290 This document and the information contained herein are provided on an 1291 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1292 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1293 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1294 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1295 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1296 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1298 Copyright Statement 1300 Copyright (C) The Internet Society (2006). This document is subject 1301 to the rights, licenses and restrictions contained in BCP 78, and 1302 except as set forth therein, the authors retain all their rights. 1304 Acknowledgment 1306 Funding for the RFC Editor function is currently provided by the 1307 Internet Society.