idnits 2.17.1 draft-delany-domainkeys-base-06.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 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1798. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1805. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1811. ** 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 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.) ** There are 6 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. ** The abstract seems to contain references ([DKIM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Recipient systems SHOULD only retrieve this policy TXT record to determine policy when an email fails to verify or does not include a signature. Recipient systems SHOULD not retrieve this policy TXT record for email that successfully verifies. Note that "testing mode" SHOULD also be in the Selector TXT record if the domain owner is running a DomainKeys test. -- 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 (25 July 2006) is 6485 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) ** Obsolete normative reference: RFC 3548 (ref. 'BASE64') (Obsoleted by RFC 4648) ** Downref: Normative reference to an Historic RFC: RFC 1421 (ref. 'PEM') -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 3851 (ref. 'SMIME') (Obsoleted by RFC 5751) Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Mark Delany 2 Title: draft-delany-domainkeys-base-06.txt Yahoo! Inc 3 Expires: 24 January 2007 25 July 2006 5 Domain-based Email Authentication Using Public Keys 6 Advertised in the DNS (DomainKeys) 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware have 12 been or will be disclosed, and any of which he or she becomes aware 13 will be disclosed, in accordance with Section 6 of BCP 79. 15 This document may not be modified, and derivative works of it may not 16 be created, except to publish it as an RFC and to translate it into 17 languages other than English. 19 Internet-Drafts are working documents of the Internet Engineering Task 20 Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 "DomainKeys" creates a domain-level authentication framework for email 37 by using public key technology and the DNS to prove the provenance and 38 contents of an email. 40 This document defines a framework for digitally signing email on a 41 per-domain basis. The ultimate goal of this framework is to 42 unequivocally prove and protect identity while retaining the semantics 43 of Internet email as it is known today. 45 Proof and protection of email identity may assist in the global 46 control of "spam" and "phishing". 48 Purpose of Submission 50 The DomainKeys specification was a primary source from which the 51 DomainKeys Identified Mail [DKIM] specification has been derived. The 52 purpose in submitting this document is as an historical reference for 53 deployed implementations written prior to the DKIM specification. 55 Table of Contents 57 1. Introduction 58 1.1 Lack of authentication is damaging Internet email 59 1.2 Digitally signed email creates credible domain authentication 60 1.3 Public keys in the DNS 61 1.4 Initial deployment is likely at the border MTA 62 1.5 Conveying verification results to MUAs 63 1.6 Technical minutiae are not completely covered 64 1.7 Motivation 65 1.8 Benefits of DomainKeys 66 1.9 Definitions 67 1.10 Requirements Notation 69 2. DomainKeys overview 71 3. DomainKeys detailed view 72 3.1 Determining the sending address of an email 73 3.2 Retrieving the public key given the sending domain 74 3.2.1 Introducing "selectors" 75 3.2.2 Public key signing and verification algorithm 76 3.2.3 Public key representation in the DNS 77 3.2.4 Key sizes 78 3.3 Storing the signature in the email header 79 3.4 Preparation of email for transit and signing 80 3.4.1 Preparation for transit 81 3.4.2 Canonicalization for signing 82 3.4.2.1 The "simple" canonicalization algorithm 83 3.4.2.2 The "nofws" canonicalization algorithm 84 3.5 The signing process 85 3.5.1 Identifying the sending domain 86 3.5.2 Determining if an email should be signed 87 3.5.3 Selecting a private key and corresponding selector information 88 3.5.4 Calculating the signature value 89 3.5.5 Prepending the "DomainKey-Signature:" header 90 3.6 Policy statement of sending domain 91 3.7 The verification process 92 3.7.1 Presumption that headers are not reordered 93 3.7.2 Verification should render a binary result 94 3.7.3 Selecting the most appropriate "DomainKey-Signature:" header 95 3.7.4 Retrieve the public key based on the signature information 96 3.7.5 Verify the signature 97 3.7.6 Retrieving sending domain policy 98 3.7.7 Applying local policy 99 3.8 Conveying verification results to MUAs 101 4. Example of use 102 4.1 The user composes an email 103 4.2 The email is signed 104 4.3 The email signature is verified 106 5. Association with a Certificate Authority 107 5.1 The "DomainKey-X509:" header 109 6. Topics for discussion 110 6.1 The benefits of selectors 111 6.2 Canonicalization of email 112 6.3 Mailing lists 113 6.4 Roving users 115 7. Security Considerations 116 7.1 DNS 117 7.1.1 The DNS is not currently secure 118 7.1.2 DomainKeys creates additional DNS load 119 7.2 Key Management 120 7.3 Implementation risks 121 7.4 Privacy assumptions with forwarding addresses 122 7.5 Cryptographic processing is computationally intensive 124 8. The trial 125 8.1 Goals 126 8.2 Results of trial 128 9. Note to implementors regarding TXT records 130 10. References 131 10.1 Normative References 132 10.2 Informative References 134 Appendix A - Syntax rules for the tag=value format 136 Acknowledgments 138 Author's Address 140 Intellectual Property and Copyright Statements 141 1. Introduction 143 This document proposes an authentication framework for email that 144 stores public keys in the DNS and digitally signs email on a domain 145 basis. Separate documents discuss how this framework can be extended 146 to validate the delivery path of email as well as facilitate per-user 147 authentication. 149 1.1 Lack of authentication is damaging Internet email 151 Authentication of email is not currently widespread. Not only is it 152 difficult to prove your own identity, it is impossible to prevent 153 others from abusing your identity. 155 While most email exchanges do not intrinsically need authentication 156 beyond context, it is the rampant abuse of identity by "spammers", 157 "phishers", and their criminal ilk that makes proof necessary. In 158 other words, authentication is as much about protection as proof. 160 Importantly, the inability to authenticate email effectively delegates 161 much of the control of the disposition of inbound email to the sender, 162 since senders can trivially assume any email address. Creating email 163 authentication is the first step to returning dispositional control of 164 email to the recipient. 166 For the purposes of this document, authentication is seen from a user 167 perspective, and is intended to answer the question "who sent this 168 email?" where "who" is the email address the recipient sees and "this 169 email" is the content that the recipient sees. 171 1.2 Digitally signing email creates credible domain authentication 173 DomainKeys combines public key cryptography and the DNS to provide 174 credible domain-level authentication for email. 176 When an email claims to originate from a certain domain, DomainKeys 177 provides a mechanism by which the recipient system can credibly 178 determine that the email did in fact originate from a person or system 179 authorized to send email for that domain. 181 The authentication provided by DomainKeys works in a number of 182 scenarios in which other authentication systems fail or create complex 183 operational requirements. These include: 185 o forwarded email 187 o distributed sending systems 188 o authorized third-party sending 190 This base definition of DomainKeys is intended to primarily enable 191 domain-level authenticity; whether a given message is really sent by 192 the purported user within the domain is outside the scope of the base 193 definition. Having said that, this specification includes the 194 possibility that some domains may wish to delegate fine-grained 195 authentication to individual users. 197 1.3 Public keys in the DNS 199 DomainKeys differs from traditional hierarchical public key systems in 200 that it leverages the DNS for public key management, placing complete 201 and direct control of key generation and management with the owner of 202 the domain. That is, if you have control over the DNS for a given 203 domain, you have control over your DomainKeys for that domain. 205 The DNS is proposed as the initial mechanism for publishing 206 public keys. DomainKeys is specifically designed to be extensible to 207 other key fetching services as they become available. 209 1.4 Initial deployment is likely at the border MTA 211 For practical reasons, it is expected that initial implementations of 212 DomainKeys will be deployed on MTAs that accept or relay email across 213 administrative or organizational boundaries. There are numerous 214 advantages to deployment at the border MTA, including: 216 o a reduction in the number of MTAs that have to be changed to 217 support an implementation of DomainKeys 219 o a reduction in the number of MTAs involved in transmitting the 220 email between a signing system and a verifying system, thus 221 reducing the number of places that can make accidental changes 222 to the contents 224 o removing the need to implement DomainKeys within an internal 225 email network. 227 However there is no necessity to deploy DomainKeys at the border as 228 signing and verifying can effectively occur anywhere from the border 229 MTA right back to the MUA. In particular the best place to sign an 230 email for many domains is likely to be at the point of SUBMISSION 231 where the sender is often authenticated through SMTP AUTH or other 232 identifying mechanisms. 234 1.5 Conveying verification results to MUAs 235 It follows that testing the authenticity of an email results in some 236 action based on the results of the test. Oftentimes the action is to 237 notify the MUA in some way - typically via a header line. 239 The "Domainkey-Status:" header is defined in this specification for 240 recording authentication results in the email. 242 1.6 Technical minutiae are not completely covered 244 The intent of this specification is to communicate the fundamental 245 characteristics of DomainKeys for an implementor. However some aspects 246 are derived from the functionality of the openssl command [OPENSSL] 247 and, rather than duplicate that documentation, implementors are 248 expected to understand the mechanics of the openssl command, 249 sufficient to complete the implementation. 251 1.7 Motivation 253 The motivation for DomainKeys is to define a simple, cheap, and 254 "sufficiently effective" mechanism by which domain owners can control 255 who has authority to send email using their domain. To this end, the 256 designers of DomainKeys set out to build a framework which: 258 o is transparent and compatible with the existing email 259 infrastructure 261 o requires no new infrastructure 263 o can be implemented independently of clients in order to 264 reduce deployment time 266 o does not require the use of a central certificate authority 267 which might impose fees for certificates or introduce delays to 268 deployment 270 o can be deployed incrementally 272 While we believe that DomainKeys meets these criteria, it is by no 273 means a perfect solution. The current Internet imposes considerable 274 compromises on any similar scheme, and readers should be careful not 275 to misinterpret the information provided in this document to imply 276 that DomainKeys makes stronger credibility statements than it is able 277 to do. 279 1.8 Benefits of DomainKeys 281 As the reader will discover, DomainKeys is solely an authentication 282 system. It is not a magic bullet for spam, nor is it an authorization 283 system, a reputation system, a certification system, or a trust 284 system. 286 However, a strong authentication system such as DomainKeys creates an 287 unimpeachable framework within which comprehensive authorization 288 systems, reputations systems and their ilk can be developed. 290 1.9 Definitions 292 With reference to the following sample email: 294 Line Data 295 Number Bytes Content 296 ---- --- -------------------------------------------- 297 01 46 From: "Joe SixPack" 298 02 40 To: "Suzie Q" 299 03 25 Subject: Is dinner ready? 300 04 43 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 301 05 40 Comment: This comment has a continuation 302 06 51 because this line begins with folding white space 303 07 60 Message-ID: <20030712040037.46341@football.example.com> 304 08 00 305 09 03 Hi. 306 10 00 307 11 37 We lost the game. Are you hungry yet? 308 12 00 309 13 04 Joe. 310 14 00 311 15 00 313 Line 01 is the first line of the email and the first line of the 314 headers. 316 Line 05 and 06 constitute the "Comment:" header. 318 Line 06 is a continuation header line. 320 Line 07 is the last line of the headers. 322 Line 08 is the empty line that separates the header from the body. 324 Line 09 is the first line of the body. 326 Line 10, 12, 14 and 15 are empty lines. 328 Line 13 is the last non-empty line of the email. 330 Line 15 is the last line of the body and the last line of the email. 332 Line 01 to 15 constitute the complete email. 334 Line 01 is earlier than line 02 and line 02 is later than line 01. 336 1.10 Requirements notation 338 This document occasionally uses terms that appear in capital letters. 339 When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD 340 NOT", and "MAY" appear capitalized, they are being used to indicate 341 particular requirements of this specification. A discussion of the 342 meanings of these terms appears in [RFC2119]. 344 2. DomainKeys overview 346 Under DomainKeys, a domain owner generates one or more private/public 347 key-pairs that will be used to sign messages originating from that 348 domain. The domain owner places the public key in his domain 349 namespace (i.e., in a DNS record associated with that domain), and 350 makes the private key available to the outbound email system. When an 351 email is submitted by an authorized user of that domain, the email 352 system uses the private key to digitally sign the email associated 353 with the sending domain. The signature is added as a header to the 354 email, and the message is transferred to its recipients in the usual 355 way. 357 When a message is received with a DomainKey signature header, the 358 receiving system can verify the signature as follows: 360 1. Extract the signature and claimed sending domain from the 361 email. 363 2. Fetch the public key from the claimed sending domain namespace. 365 3. Use public key to determine whether the signature of the email 366 has been generated with the corresponding private key, and thus 367 whether the email was sent with the authority of the claimed 368 sending domain. 370 In the event that an email arrives without a signature or when the 371 signature verification fails, the receiving system retrieves the 372 policy of the claimed sending domain to ascertain the preferred 373 disposition of such email. 375 Armed with this information, the recipient system can apply local 376 policy based on the results of the signature test. 378 3. DomainKeys detailed view 380 This section discusses the specifics of DomainKeys that are needed to 381 create interoperable implementations. This section answers the 382 following questions: 384 Given an email, how is the sending domain determined? 386 How is the public key retrieved for a sending domain? 388 As email transits the email system, it can potentially go through a 389 number of changes. Which parts of the email are included in the 390 signature and how are they protected from such transformations? 392 How is the signature represented in the email? 394 If a signature is not present, or a verification fails, how does the 395 recipient determine the policy intent of the sending domain? 397 Finally, on verifying the authenticity of an email, how is that 398 result conveyed to participating MUAs? 400 While there are many alternative design choices, most lead to 401 comparable functionality. The overriding selection criteria used to 402 choose amongst the alternatives are: 404 o use deployed technology whenever possible 406 o prefer ease of implementation 408 o avoid trading risk for excessive flexibility or interoperability 410 o include basic flexibility 412 Adherence to these criteria implies that some existing email 413 implementations will require changes to participate in DomainKeys. 414 Ultimately some hard choices need to be made regarding which 415 requirements are more important. 417 3.1 Determining the sending address of an email 419 The goal of DomainKeys is to give the recipient confidence that the 420 email originated from the claimed sender. As with much of Internet 421 email, agreement over what constitutes the "sender" is no easy 422 matter. Forwarding systems and mailing lists add serious complications 423 to an overtly simple question. From the point of view of the 424 recipient, the authenticity claim should be directed at the domain 425 most visible to the recipient. 427 In the first instance, the most visible address is clearly the RFC2822 428 "From:" address [RFC2822]. Therefore, a conforming email MUST contain 429 a single "From:" header from which an email address with a domain name 430 can be extracted. 432 A conforming email MAY contain a single RFC2822 "Sender:" header from 433 which an email address with a domain name can be extracted. 435 If the email has a valid "From:" and a valid "Sender:" header, then 436 the signer MUST use the sending address in the "Sender:" header. 438 If the email has a valid "From:" and no "Sender:" header, then the 439 signer MUST use the first sending address in the "From:" header. 441 In all other cases, a signer MUST NOT sign the email. Implementors 442 should note the an email with a "Sender:" header and no "From:" header 443 MUST NOT be signed. 445 The domain name in the sending address constitutes the "sending 446 domain". 448 3.2 Retrieving the public key given the sending domain 450 To avoid namespace conflicts, it is proposed that the DNS namespace 451 "_domainkey." be reserved within the sending domain for storing 452 public keys, e.g., if the sending domain is example.net, then the 453 public keys for that domain are stored in the _domainkey.example.net 454 namespace. 456 3.2.1 Introducing "selectors" 458 To support multiple concurrent public keys per sending domain, the DNS 459 namespace is further subdivided with "selectors". Selectors are 460 arbitrary names below the "_domainkey." namespace. A selector value 461 and length MUST be legal in the DNS namespace and in email headers 462 with the additional provision that they cannot contain a semicolon. 464 Examples of namespace using selectors are: 466 "coolumbeach._domainkey.example.net" 467 "sebastopol._domainkey.example.net" 468 "reykjavik._domainkey.example.net" 469 "default._domainkey.example.net" 471 and 473 "2005.pao._domainkey.example.net" 474 "2005.sql._domainkey.example.net" 475 "2005.rhv._domainkey.example.net" 477 Periods are allowed in selectors and are to be treated as component 478 separators. In the case of DNS queries that means the period defines 479 sub-domain boundaries. 481 The number of public keys and corresponding selectors for each domain 482 are determined by the domain owner. Many domain owners will be 483 satisfied with just one selector whereas administratively distributed 484 organizations may choose to manage disparate selectors and key pairs 485 in different regions or on different email servers. 487 Beyond administrative convenience, selectors make it possible to 488 seamlessly replace public keys on a routine basis. If a domain wishes 489 to change from using a public key associated with selector "2005" to a 490 public key associated with selector "2006", it merely makes sure that 491 both public keys are advertised in the DNS concurrently for the 492 transition period during which email may be in transit prior to 493 verification. At the start of the transition period, the outbound 494 email servers are configured to sign with the "2006" private key. At 495 the end of the transition period, the "2005" public key is removed 496 from the DNS. 498 While some domains may wish to make selector values well known, others 499 will want to take care not to allocate selector names in a way that 500 allows harvesting of data by outside parties. E.g., if per-user keys 501 are issued, the domain owner will need to make the decision as to 502 whether to make this selector associated directly with the user name, 503 or make it some unassociated random value, such as the fingerprint of 504 the public key. 506 3.2.2 Public key signing and verification algorithm 508 The default signature is an RSA signed SHA1 digest of the complete 509 email. 511 For ease of explanation, the openssl command is used throughout this 512 document to describe the mechanism by which keys and signatures are 513 managed. 515 One way to generate a 768 bit private key suitable for DomainKeys, is 516 to use openssl like this: 518 $ openssl genrsa -out rsa.private 768 520 Which results in the file rsa.private containing the key information 521 similar to this: 523 -----BEGIN RSA PRIVATE KEY----- 524 MIIByQIBAAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6lMIgulclWjZwP56LRqdg5 525 ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7EXzVc+nRLWT1kwTvFNGIo 526 AUsFUq+J6+OprwIDAQABAmBOX0UaLdWWusYzNol++nNZ0RLAtr1/LKMX3tk1MkLH 527 +Ug13EzB2RZjjDOWlUOY98yxW9/hX05Uc9V5MPo+q2Lzg8wBtyRLqlORd7pfxYCn 528 Kapi2RPMcR1CxEJdXOkLCFECMQDTO0fzuShRvL8q0m5sitIHlLA/L+0+r9KaSRM/ 529 3WQrmUpV+fAC3C31XGjhHv2EuAkCMQDE5U2nP2ZWVlSbxOKBqX724amoL7rrkUew 530 ti9TEjfaBndGKF2yYF7/+g53ZowRkfcCME/xOJr58VN17pejSl1T8Icj88wGNHCs 531 FDWGAH4EKNwDSMnfLMG4WMBqd9rzYpkvGQIwLhAHDq2CX4hq2tZAt1zT2yYH7tTb 532 weiHAQxeHe0RK+x/UuZ2pRhuoSv63mwbMLEZAjAP2vy6Yn+f9SKw2mKuj1zLjEhG 533 6ppw+nKD50ncnPoP322UMxVNG4Eah0GYJ4DLP0U= 534 -----END RSA PRIVATE KEY----- 536 Once a private key has been generated, the openssl command can be used 537 to sign an appropriately prepared email, like this: 539 $ openssl dgst -sign rsa.private -sha1 1306 To: "Suzie Q" 1307 Subject: Is dinner ready? 1308 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 1309 Message-ID: <20030712040037.46341.5F8J@football.example.com> 1311 Hi. 1313 We lost the game. Are you hungry yet? 1315 Joe. 1317 4.2 The email is signed 1319 This email is signed by the football.example.com outbound email server 1320 and now looks like this: 1322 DomainKey-Signature: a=rsa-sha1; s=brisbane; d=football.example.com; 1323 c=simple; q=dns; 1324 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ 1325 VoG4ZHRNiYzR; 1326 Received: from dsl-10.2.3.4.football.example.com [10.2.3.4] 1327 by submitserver.football.example.com with SUBMISSION; 1328 Fri, 11 Jul 2003 21:01:54 -0700 (PDT) 1329 From: "Joe SixPack" 1330 To: "Suzie Q" 1331 Subject: Is dinner ready? 1332 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 1333 Message-ID: <20030712040037.46341.5F8J@football.example.com> 1335 Hi. 1337 We lost the game. Are you hungry yet? 1339 Joe. 1341 The signing email server requires access to the private key associated 1342 with the "brisbane" selector to generate this signature. Distribution 1343 and management of private keys is outside the scope of this document. 1345 4.3 The email signature is verified 1347 The signature is normally verified by an inbound SMTP server or 1348 possibly the final delivery agent. However, intervening MTAs can also 1349 perform this verification if they choose to do so. 1351 The verification process uses the domain "football.example.com" 1352 extracted from the "From:" header and the selector "brisbane" from the 1353 "DomainKey-Signature:" header to form the DNS TXT query for: 1355 brisbane._domainkey.football.example.com 1357 Since there is no "h" tag in the "DomainKey-Signature:" header, 1358 signature verification starts with the line following the 1359 "DomainKey-Signature:" line. The email is canonically prepared for 1360 verifying with the "simple" method. 1362 The result of the query and subsequent verification of the signature 1363 is stored in the "DomainKey-Status:" header line. After successful 1364 verification, the email looks like this: 1366 DomainKey-Status: good 1367 from=joe@football.example.com; domainkeys=pass 1368 Received: from mout23.brisbane.football.example.com (192.168.1.1) 1369 by shopping.example.net with SMTP; 1370 Fri, 11 Jul 2003 21:01:59 -0700 (PDT) 1371 DomainKey-Signature: a=rsa-sha1; s=brisbane; d=football.example.com; 1372 c=simple; q=dns; 1373 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ 1374 VoG4ZHRNiYzR; 1375 Received: from dsl-10.2.3.4.network.example.com [10.2.3.4] 1376 by submitserver.example.com with SUBMISSION; 1377 Fri, 11 Jul 2003 21:01:54 -0700 (PDT) 1378 From: "Joe SixPack" 1379 To: "Suzie Q" 1380 Subject: Is dinner ready? 1381 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 1382 Message-ID: <20030712040037.46341.5F8J@football.example.com> 1384 Hi. 1386 We lost the game. Are you hungry yet? 1388 Joe. 1390 5. Association with a Certificate Authority 1392 A fundamental aspect of DomainKeys is that public keys are generated 1393 and advertised by each domain at no additional cost. This 1394 accessibility markedly differs from traditional Public Key 1395 Infrastructures where there is typically a Certificate Authority (CA) 1396 who validates an applicant and issues a signed certificate - 1397 containing their public key - often for a recurring fee. 1399 While CAs do impose costs, they also have the potential to provide 1400 additional value as part of their certification process. Consider 1401 financial institutions, public utilities, law enforcement agencies and 1402 the like. In many cases, such entities justifiably need to 1403 discriminate themselves above and beyond the authentication that 1404 DomainKeys offers. 1406 Creating a link between DomainKeys and CA issued certificates has the 1407 potential to access additional authentication mechanisms that are more 1408 authoritative than domain owner issued authentication. It is well 1409 beyond the scope of this specification to describe such authorities 1410 apart from defining how the linkage could be achieved with the 1411 "DomainKey-X509:" header. 1413 5.1 The "DomainKey-X509:" header 1415 The "DomainKey-X509:" header provides a link between the public key 1416 used to sign the email and the certificate issued by a CA. 1418 The exact content, syntax and semantics of this header are yet to be 1419 resolved. One possibility is that this header contains an encoding of 1420 the certificate issued by a CA. Another possibility is that this 1421 header contains a URL that points to a certificate issued by a CA. 1423 In either case, this header can only be consulted if the signature 1424 verifies and MUST be part of the content signed by the corresponding 1425 "DomainKey-Signature:" header. Furthermore, it is likely that MUAs 1426 rather than MTAs will confirm that the link to the CA issued 1427 certificate is valid. In part this is because many MUAs already have 1428 built-in capabilities as a consequence of S/MIME [SMIME] and SSL [SSL] 1429 support. 1431 The proof of linkage is made by testing that the public key in the 1432 certificate matches the public key used to sign the email. 1434 An example of a email containing the "DomainKey-X509:" header is: 1436 DomainKey-Signature: a=rsa-sha1; s=statements; 1437 d=largebank.example.com; c=simple; q=dns; 1438 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ 1439 VoG4ZHRNiYzR; 1440 DomainKey-X509: https://ca.example.net/largebank.example.com 1441 From: "Large Bank" 1442 To: "Suzie Q" 1443 Subject: Statement for Account: 1234-5678 1444 ... 1446 The format of the retrieved value from the URL is not yet defined, nor 1447 is the determination of valid CAs. 1449 The whole matter of linkage to CA issued certificates is one aspect of 1450 DomainKeys that needs to be resolved with relevant CA and certificate 1451 issuing entities. The primary point is that a link is possible to a 1452 higher authority. 1454 6. Topics for discussion 1456 6.1 The benefits of selectors 1458 Selectors are at the heart of the flexibility of DomainKeys. A domain 1459 administrator is free to use a single DomainKey for all outbound 1460 mail. Alternatively, they may use many DomainKeys differentiated by 1461 selector and assign each key to different servers. 1463 For example, a large outbound email farm might have a unique DomainKey 1464 for each server, and thus their DNS will advertise potentially 1465 hundreds of keys via their unique selectors. 1467 Another example is a corporate email administrator who might generate a 1468 separate DomainKey for each regional office email server. 1470 In essence, selectors allow a domain owner to distribute authority to 1471 send on behalf of that domain. Combined with the ability to revoke by 1472 removal or TTL expiration, a domain owner has coarse-grained control 1473 over the duration of the distributed authority. 1475 Selectors are particularly useful for domain owners who want to 1476 contract a third-party mailing system to send a particular set of 1477 mail. The domain owner can generate a special key pair and selector 1478 just for this mail-out. The domain owner has to provide the Private 1479 Key and selector to the third party for the life of the 1480 mail-out. However, as soon as the mail-out is completely delivered, 1481 the domain owner can revoke the public key by the simple expedient of 1482 removing the entry from the DNS. 1484 6.2 Canonicalization of email 1486 It is an unfortunate fact that some email software routinely (and 1487 often unnecessarily) transforms email as it transits through the 1488 network. Such transformations conflict with the fundamental purpose of 1489 cryptographic signatures - to detect modifications. 1491 While two canonicalization algorithms are defined in this 1492 specification, the primary goal of "nofws" is to provide a transition 1493 path to "simple". With a mixture of "simple" and "nofws" email, a 1494 receiver can determine which systems are modifying email in ways that 1495 cause the signature to fail and thus provide feedback to the modifying 1496 system. 1498 6.3 Mailing lists 1500 Integrating existing Mailing List Managers (MLMs) into the DomainKeys 1501 authentication system is a complicated areas as the behavior of MLMs is 1502 highly variable. Essentially there are two types of MLMs under 1503 consideration. Those that modify email to such an extent that 1504 verification of the original content is not possible, and MLMs that 1505 make minimal or no modifications to an email. 1507 MLMs that modify email in a way that causes verification to fail, MUST 1508 pre-pend either a "Sender:" header and preferably a "List-ID:" header 1509 and arrange for the email to be resigned as it is distributed to the 1510 list recipients. 1512 A participating SUBMISSION server can deduce the need to resign such 1513 an email by the presence of a "Sender:" or "List-ID:" header from an 1514 authorized submission. 1516 MLMs that do not modify email in a way that causes verification to 1517 fail, MAY perform the same actions as a modifying MLM. 1519 6.4 Roving users 1521 One scenario that presents a particular problem with any form of email 1522 authentication, including DomainKeys, is the roving user. A user who 1523 is obliged to use a third-party SUBMISSION service when unable to 1524 connect to their own SUBMISSION service. The classic example cited is 1525 a traveling salesperson being redirected to a hotel email server to 1526 send email. 1528 As far as DomainKeys is concerned, email of this nature clearly 1529 originates from an email server that does not have authority to send 1530 on behalf of the domain of the salesperson and is therefore 1531 indistinguishable from a forgery. While DomainKeys does not prescribe 1532 any specific action for such email it is likely that over time, such 1533 email will be treated as second class email. 1535 The typical solution offered to roving users is to submit email via an 1536 authorized server for their domain - perhaps via a VPN or a web 1537 interface or even SMTP AUTH back to a SUBMISSION server. 1539 While these are perfectly acceptable solutions for many, they are not 1540 necessarily solutions that are available or possible for all such 1541 users. 1543 One possible way to address the needs of this contingent of 1544 potentially disenfranchised users, is for the domain to issue per-user 1545 DomainKeys. Per-user DomainKeys are identified by a non-empty "g" tag 1546 value in the corresponding DNS record. 1548 7. Security Considerations 1549 7.1 DNS 1551 DomainKeys is primarily a security mechanism. Its core purpose is to 1552 make claims about email authentication in a credible way. However, 1553 DomainKeys, like virtually all Internet applications, relies on the 1554 DNS which has well-known security flaws [RFC3833]. 1556 7.1.1 The DNS is not currently secure 1558 While the DNS is currently insecure, it is expected that the security 1559 problems should and will be solved by DNSSEC [DNSSEC], and all users 1560 of the DNS will reap the benefit of that work. 1562 Secondly, the types of DNS attacks relevant to DomainKeys are very 1563 costly and are far less rewarding than DNS attacks on other Internet 1564 applications. 1566 To systematically thwart the intent of DomainKeys, an attacker must 1567 conduct a very costly and very extensive attack on many parts of the 1568 DNS over an extended period. No one knows for sure how attackers will 1569 respond, however the cost/benefit of conducting prolonged DNS attacks 1570 of this nature is expected to be uneconomical. 1572 Finally, DomainKeys is only intended as a "sufficient" method of 1573 proving authenticity. It is not intended to provide strong 1574 cryptographic proof about authorship or contents. Other technologies 1575 such as GnuPG and S/MIME address those requirements. 1577 7.1.2 DomainKeys creates additional DNS load 1579 A second security issue related to the DNS revolves around the 1580 increased DNS traffic as a consequence of fetching Selector-based data 1581 as well as fetching sending domain policy. Widespread deployment of 1582 DomainKeys will result in a significant increase in DNS queries to the 1583 claimed sending domain. In the case of forgeries on a large scale, DNS 1584 servers could see a substantial increase in queries. 1586 7.2 Key Management 1588 All public key systems require management of key pairs. Private keys 1589 in particular need to be securely distributed to each signing mail 1590 server and protected on those servers. For those familiar with SSL, 1591 the key management issues are similar to those of managing SSL 1592 certificates. Poor key management may result in unauthorized access to 1593 private keys, which in essence gives unauthorized access to your 1594 identity. 1596 7.3 Implementation Risks 1598 It is well recognized in cryptographic circles that many security 1599 failures are caused by poor implementations rather than poor 1600 algorithms. For example, early SSL implementations were vulnerable 1601 because the implementors used predictable "random numbers". 1603 While some MTA software already supports various cryptographic 1604 techniques, such as TLS, many do not. This proposal introduces 1605 cryptographic requirements into MTA software which implies a much 1606 higher duty of care to manage the increased risk. 1608 There are numerous articles, books, courses, and consultants that help 1609 programming security applications. Potential implementors are strongly 1610 encouraged to avail themselves of all possible resources to ensure 1611 secure implementations. 1613 7.4 Privacy assumptions with forwarding addresses 1615 Some people believe that they can achieve anonymity by using an email 1616 forwarding service. While this has never been particularly true as 1617 bounces, over-quota messages, vacation messages and web bugs all 1618 conspire to expose IP addresses and domain names associated with the 1619 delivery path, the DNS queries that are required to verify DomainKeys 1620 signature can provide additional information to the sender. 1622 In particular, as mail is forwarded through the mail network, the DNS 1623 queries for the selector will typically identify the DNS cache used by 1624 the forwarding and delivery MTAs. 1626 7.5 Cryptographic processing is computationally intensive 1628 Verifying a signature is computationally significant. Early 1629 indications are that a typical mail server can expect to increase CPU 1630 demands by 8-15 percent. While this increased demand is modest 1631 compared to other common mail processing costs - such as Bayesian 1632 filtering - any increase in resource requirements can make a 1633 denial-of-service attack more effective against a mail system. 1635 A constraining factor of such attacks is that the net computational 1636 cost of verifying is bounded by the maximum key size allowed by this 1637 specification and is essentially linear to the rate at which mail is 1638 accepted by the verifying system. Consequently, the additional 1639 computational cost may augment a denial-of-service attack, but it does 1640 not add a non-linear component to such attacks. 1642 8. The trial 1643 The Domainkeys protocol was deployed as a trial to better understand 1644 the implications of deploying wide-scale cryptographic email 1645 authentication. 1647 Open Source implementations were made available at various places, 1648 particularly Source Forge [SOURCEFORGE] which includes links to 1649 numerous implementations, both Open Source and commercial. 1651 8.1 Goals 1653 The primary goals of the trial were to: 1655 o understand the operational implications of running a DNS-based 1656 public key system for email 1658 o measure the effectiveness of the canonicalization algorithms 1660 o experiment with possible per-user key deployment models 1662 o fully define the semantics of the "DomainKey-X509:" header 1664 8.2 Results of trial 1666 The DomainKeys trial ran for approximately 2 years in which time 1667 numerous large ISPs and many thousands of smaller domains participated 1668 in signing or verifying with DomainKeys. The low order numbers are 1669 that at least one billion DomainKey signed emails transit the Internet 1670 each day between some 12,000 participating domains. 1672 The operational and development experience of that trial was applied 1673 to DKIM. 1675 9. Note to Implementors regarding TXT records 1677 The DNS is very flexible in that it is possible to have multiple TXT 1678 records for a single name and for those TXT records to contain 1679 multiple strings. 1681 In all cases, implementors of DomainKeys should expect a single TXT 1682 record for any particular name. If multiple TXT records are returned, 1683 the implementation is free to pick any single TXT record as the 1684 authoritative data. In other words, if a name server returns different 1685 TXT records for the same name, it can expect unpredictable results. 1687 Within a single TXT record, implementors should concatenate multiple 1688 strings in the order presented and ignore string boundaries. Note that 1689 a number of popular DNS command-line tools render multiple strings as 1690 separately quoted strings which can be misleading to a novice 1691 implementor. 1693 10. References 1695 10.1 Normative References 1697 [BASE64] S. Josefsson, Ed., "The Base16, Base32, and Base64 1698 Data Encodings", RFC 3548, July, 2003. 1700 [PEM] Linn, J., "Privacy Enhancement for Internet Electronic 1701 Mail: Part I: Message Encryption and Authentication 1702 Procedures", RFC 1421 February, 1993. 1704 10.2 Informative References 1706 [DKIM] http://www.ietf.org/html.charters/dkim-charter.html 1708 [DNSSEC] http://www.ietf.org/html.charters/dnsext-charter.html 1710 [OPENSSL] http://www.openssl.org 1712 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1713 Requirement Levels", RFC 2119, March 1997. 1715 [RFC2822] Resnick, P., Editor, "Internet Message Format", RFC 1716 2822, April 2001. 1718 [RFC3833] Atkins, D., Austein, R., "Threat Analysis of the 1719 Domain Name System (DNS)", RFC 3833, August, 2004. 1721 [SMIME] B. Ramsdell, Editor, "Secure/Multipurpose Internet 1722 Mail Extensions (S/MIME) Version 3.1 Message 1723 Specification", RFC 3851, July 2004. 1725 [SOURCEFORGE] http://domainkeys.sourceforge.net 1727 [SSL] http://wp.netscape.com/security/techbriefs/ssl.html 1729 Appendix A - Syntax rules for the tag=value format 1731 A simple tag=value syntax is used to encode data in the response 1732 values for DNS queries as well as headers embedded in emails. This 1733 section summarized the syntactic rules for this encoding: 1735 o A tag=value pair consists of three tokens, a "tag", the "=" 1736 character and the "value" 1738 o A tag MUST be one character long and MUST be a lower-case 1739 alphabetic character 1741 o Duplicate tags are not allowed 1743 o A value MUST only consist of characters that are valid in 1744 RFC2822 headers, DNS TXT records and are within the ASCII range 1745 of characters from SPACE (0x20) to TILDE (0x7E) 1746 inclusive. Values MUST NOT contain a semicolon but they may 1747 contain "=" characters. 1749 o A tag=value pair MUST be terminated by a semicolon or the end 1750 of the data 1752 o Values MUST be processed as case sensitive unless the specific 1753 tag description of semantics imply case insensitivity. 1755 o Values MAY be zero bytes long 1757 o Whitespace MAY surround any of the tokens, however whitespace 1758 within a value MUST be retained unless explicitly excluded by 1759 the specific tag description. Currently the only tags that 1760 specifically ignores embedded whitespace are the "b" and "h" tag 1761 in the "DomainKey-Signature:" header. 1763 o Tag=value pairs that represent the default value MAY be included 1764 to aid legibility. 1766 o Unrecognized tags MUST be ignored 1768 Acknowledgments 1770 The editor wishes to thank Russ Allbery, Eric Allman, Edwin Aoki, 1771 Claus Asmann, Steve Atkins, Jon Callas, Dave Crocker, Michael Cudahy, 1772 Jutta Degener, Timothy Der, Jim Fenton, Duncan Findlay, Phillip 1773 Hallam-Baker, Murray S. Kucherawy, John Levine, Miles Libbey, David 1774 Margrave, Justin Mason, David Mayne, Russell Nelson, Juan Altmayer 1775 Pizzorno, Blake Ramsdell, Scott Renfro, the Spamhaus.org team, Malte 1776 S. Stretz, Robert Sanders, Bradley Taylor, and Rand Wacker for their 1777 valuable suggestions and constructive criticism. 1779 Author's Address 1781 Mark Delany 1782 Yahoo! Inc 1783 701 First Avenue 1784 Sunnyvale, CA 95087 1785 USA 1787 Email: markd+domainkeys@yahoo-inc.com 1789 Intellectual Property Statement 1791 The IETF takes no position regarding the validity or scope of any 1792 Intellectual Property Rights or other rights that might be claimed 1793 to pertain to the implementation or use of the technology described 1794 in this document or the extent to which any license under such 1795 rights might or might not be available; nor does it represent that 1796 it has made any independent effort to identify any such rights. 1797 Information on the procedures with respect to rights in RFC 1798 documents can be found in BCP 78 and BCP 79. 1800 Copies of IPR disclosures made to the IETF Secretariat and any 1801 assurances of licenses to be made available, or the result of an 1802 attempt made to obtain a general license or permission for the use 1803 of such proprietary rights by implementers or users of this 1804 specification can be obtained from the IETF on-line IPR repository 1805 at http://www.ietf.org/ipr. 1807 The IETF invites any interested party to bring to its attention any 1808 copyrights, patents or patent applications, or other proprietary 1809 rights that may cover technology that may be required to implement 1810 this standard. Please address the information to the IETF at 1811 ietf-ipr@ietf.org. 1813 The IETF has been notified of intellectual property rights claimed 1814 in regard to some or all of the specification contained in this 1815 document. For more information consult the online list of claimed 1816 rights. 1818 Disclaimer of Validity 1820 This document and the information contained herein are provided on 1821 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1822 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1823 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1824 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1825 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1826 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1827 PARTICULAR PURPOSE. 1829 Copyright Statement 1831 Copyright (C) The Internet Society (2006). This document is 1832 subject to the rights, licenses and restrictions contained in BCP 1833 78, and except as set forth therein, the authors retain all their 1834 rights.