idnits 2.17.1 draft-allman-dkim-base-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2265. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2272. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2278. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 94 has weird spacing: '...Results heade...' == Line 902 has weird spacing: '...Results heade...' == Line 975 has weird spacing: '... email elec...' -- 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 (October 23, 2005) is 6753 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'XREF-TBD' is mentioned on line 783, but not defined == Missing Reference: 'MIME' is mentioned on line 2194, but not defined == Unused Reference: 'OPENSSL' is defined on line 1822, but no explicit reference was found in the text == Unused Reference: 'RFC1421' is defined on line 1825, but no explicit reference was found in the text == Unused Reference: 'RFC3491' is defined on line 1850, but no explicit reference was found in the text == Unused Reference: 'ID-DKIM-THREATS' is defined on line 1859, but no explicit reference was found in the text -- No information found for draft-dkk-rr-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ID-DKIM-RR' -- No information found for draft-allman-dkim-ssp-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ID-DKIM-SSP' == Outdated reference: A later version (-14) exists of draft-crocker-email-arch-02 ** Downref: Normative reference to an Informational draft: draft-crocker-email-arch (ref. 'ID-MAIL-ARCH') -- Possible downref: Non-RFC (?) normative reference: ref. 'OPENSSL' ** Downref: Normative reference to an Historic RFC: RFC 1421 ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 3491 (Obsoleted by RFC 5891) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) == Outdated reference: A later version (-02) exists of draft-fenton-dkim-threats-00 -- Obsolete informational reference (is this intentional?): RFC 2440 (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 2633 (Obsoleted by RFC 3851) Summary: 10 errors (**), 0 flaws (~~), 13 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DKIM E. Allman 3 Internet-Draft Sendmail, Inc. 4 Expires: April 26, 2006 J. Callas 5 PGP Corporation 6 M. Delany 7 M. Libbey 8 Yahoo! Inc 9 J. Fenton 10 M. Thomas 11 Cisco Systems, Inc. 12 October 23, 2005 14 DomainKeys Identified Mail (DKIM) 15 draft-allman-dkim-base-01 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on April 26, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 DomainKeys Identified Mail (DKIM) defines a domain-level 49 authentication framework for email using public-key cryptography and 50 key server technology to permit verification of the source and 51 contents of messages by either Mail Transfer Agents (MTAs) or Mail 52 User Agents (MUAs). The ultimate goal of this framework is to permit 53 a signing domain to assert responsibility for a message, thus proving 54 and protecting message sender identity and the integrity of the 55 messages they convey while retaining the functionality of Internet 56 email as it is known today. Proof and protection of email identity, 57 including repudiation and non-repudiation, may assist in the global 58 control of "spam" and "phishing". 60 Requirements Language 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in [RFC2119]. 66 (Unresolved Issues/To Be Done) 68 Security Considerations needs further work. 70 Need to add new and check existing ABNF. 72 Need to resolve remaining cross references (XINDX and XREF). 74 Need to clean up or eliminate appendices. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 79 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 1.2 Signing Identity . . . . . . . . . . . . . . . . . . . . . 6 81 1.3 Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 82 1.4 Simple Key Management . . . . . . . . . . . . . . . . . . 6 83 2. Terminology and Definitions . . . . . . . . . . . . . . . . 6 84 2.1 Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6 85 2.2 Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 86 2.3 White Space . . . . . . . . . . . . . . . . . . . . . . . 7 87 2.4 Imported ABNF tokens . . . . . . . . . . . . . . . . . . . 7 88 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . 8 89 3.1 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 8 90 3.2 Tag=Value Format for DKIM header fields . . . . . . . . . 9 91 3.3 Signing and Verification Algorithms . . . . . . . . . . . 10 92 3.4 Canonicalization . . . . . . . . . . . . . . . . . . . . . 11 93 3.5 The DKIM-Signature header field . . . . . . . . . . . . . 15 94 3.6 The Authentication-Results header field . . . . . . . . . 21 95 3.7 Key Management and Representation . . . . . . . . . . . . 21 96 3.8 Computing the Message Hash . . . . . . . . . . . . . . . . 23 97 4. Semantics of Multiple Signatures . . . . . . . . . . . . . . 25 98 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . 25 99 5.1 Determine if the Email Should be Signed and by Whom . . . 25 100 5.2 Select a private-key and corresponding selector 101 information . . . . . . . . . . . . . . . . . . . . . . . 26 102 5.3 Normalize the Message to Prevent Transport Conversions . . 26 103 5.4 Determine the header fields to Sign . . . . . . . . . . . 27 104 5.5 Compute the Message Hash . . . . . . . . . . . . . . . . . 29 105 5.6 Insert the DKIM-Signature header field . . . . . . . . . . 30 106 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . 30 107 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 30 108 6.2 Extract the Signature from the Message . . . . . . . . . . 30 109 6.3 Get the Public Key . . . . . . . . . . . . . . . . . . . . 31 110 6.4 Compute the Verification . . . . . . . . . . . . . . . . . 32 111 6.5 Apply Sender Signing Policy . . . . . . . . . . . . . . . 33 112 6.6 Interpret Results/Apply Local Policy . . . . . . . . . . . 34 113 7. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . 36 114 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 36 115 9. Security Considerations . . . . . . . . . . . . . . . . . . 36 116 9.1 Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 36 117 9.2 Misappropriated Private Key . . . . . . . . . . . . . . . 37 118 9.3 Key Server Denial-of-Service Attacks . . . . . . . . . . . 38 119 9.4 Attacks Against DNS . . . . . . . . . . . . . . . . . . . 38 120 9.5 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 39 121 9.6 Limits on Revoking Keys . . . . . . . . . . . . . . . . . 39 122 9.7 Intentionally malformed Key Records . . . . . . . . . . . 39 123 9.8 Intentionally Malformed DKIM-Signature header fields . . . 40 125 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 126 10.1 References -- Normative . . . . . . . . . . . . . . . . 40 127 10.2 References -- Informative . . . . . . . . . . . . . . . 41 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 42 129 A. Usage Examples (INFORMATIVE) . . . . . . . . . . . . . . . . 43 130 A.1 Simple message transfer . . . . . . . . . . . . . . . . . 43 131 A.2 Outsourced business functions . . . . . . . . . . . . . . 43 132 A.3 PDAs and Similar Devices . . . . . . . . . . . . . . . . . 44 133 A.4 Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 44 134 A.5 Affinity Addresses . . . . . . . . . . . . . . . . . . . . 45 135 A.6 Third-party Message Transmission . . . . . . . . . . . . . 45 136 B. Example of Use (INFORMATIVE) . . . . . . . . . . . . . . . . 45 137 B.1 The user composes an email . . . . . . . . . . . . . . . . 46 138 B.2 The email is signed . . . . . . . . . . . . . . . . . . . 46 139 B.3 The email signature is verified . . . . . . . . . . . . . 47 140 C. Creating a public key (INFORMATIVE) . . . . . . . . . . . . 48 141 D. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 142 E. Edit History . . . . . . . . . . . . . . . . . . . . . . . . 50 143 E.1 Changes since -00 version . . . . . . . . . . . . . . . . 50 144 Intellectual Property and Copyright Statements . . . . . . . 51 146 1. Introduction 148 1.1 Overview 150 DomainKeys Identified Mail (DKIM) defines a simple, low cost, and 151 effective mechanism by which email messages can be cryptographically 152 signed, permitting a signing domain to claim responsibility for the 153 use of a given email address. Message recipients can verify the 154 signature by querying the signer's domain directly to retrieve the 155 appropriate public key, and thereby confirm that the message was 156 attested to by a party in possession of the private key for the 157 signing domain. 159 The approach taken by DKIM differs from previous approaches to 160 message signing (e.g. S/MIME [RFC1847], OpenPGP [RFC2440]) in that: 162 o the message signature is written to the message header fields so 163 that neither human recipients nor existing MUA (Mail User Agent) 164 software are confused by signature-related content appearing in 165 the message body, 167 o there is no dependency on public and private key pairs being 168 issued by well-known, trusted certificate authorities, 170 o there is no dependency on the deployment of any new Internet 171 protocols or services for public key distribution or revocation, 173 o it makes no attempt to include encryption as part of the 174 mechanism. 176 DKIM: 178 o is transparent and compatible with the existing email 179 infrastructure 181 o requires minimal new infrastructure 183 o can be implemented independently of clients in order to reduce 184 deployment time 186 o does not require the use of a trusted third party (such as a 187 certificate authority or other entity) which might impose 188 significant costs or introduce delays to deployment 190 o can be deployed incrementally 192 o allows delegation of signing to third parties. 194 A "selector" mechanism allows multiple keys per domain, including 195 delegation of the right to authenticate a portion of the namespace to 196 a trusted third party. 198 1.2 Signing Identity 200 DKIM separates the question of the signer of the message from the 201 purported author of the message. In particular, a signature includes 202 the identity of the signer. Recipients can use the signing 203 information to decide how they want to process the message. 205 INFORMATIVE RATIONALE: The signing address associated with a DKIM 206 signature is not required to match a particular header field 207 because of the broad methods of interpretation by recipient mail 208 systems, including MUAs. 210 1.3 Scalability 212 The email identification problem is characterized by extreme 213 scalability requirements. There are currently over 70 million 214 domains and a much larger number of individual addresses. It is 215 important to preserve the positive aspects of the current email 216 infrastructure, such as the ability for anyone to communicate with 217 anyone else without introduction. 219 1.4 Simple Key Management 221 DKIM differs from traditional hierarchical public-key systems in that 222 no key signing infrastructure is required; the verifier requests the 223 public key from the claimed signer directly. 225 The DNS is proposed as the initial mechanism for publishing public 226 keys. DKIM is designed to be extensible to other key fetching 227 services as they become available. 229 2. Terminology and Definitions 231 2.1 Signers 233 Elements in the mail system that sign messages are referred to as 234 signers. These may be MUAs (Mail User Agents), MSAs (Mail Submission 235 Agents), MTAs (Mail Transfer Agents), or other agents such as mailing 236 list exploders. In general any signer will be involved in the 237 injection of a message into the message system in some way. The key 238 issue is that a message must be signed before it leaves the 239 administrative domain of the signer. 241 2.2 Verifiers 243 Elements in the mail system that verify signatures are referred to as 244 verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs. 245 In most cases it is expected that verifiers will be close to an end 246 user (reader) of the message or some consuming agent such as a 247 mailing list exploder. 249 2.3 White Space 251 There are three forms of white space: 253 o WSP represents simple white space, i.e., a space or a tab 254 character, and is inherited from [RFC2822]. 256 o SWSP is streaming white space; it adds the CR and LF characters. 258 o FWS, also from [RFC2822], is folding white space. It allows 259 multiple lines separated by CRLF followed by at least one white 260 space, to be joined. 262 Using the syntax of [RFC4234], the formal ABNF for SWSP is: 264 SWSP = CR / LF / WSP ; streaming white space 266 Other terminology is based on [ID-MAIL-ARCH]. 268 2.4 Imported ABNF tokens 270 The following tokens are imported from other RFCs as noted. Those 271 RFCs should be considered definitive. However, all tokens having 272 names beginning with "obs-" should be excluded from this import. 274 The following tokens are imported from [RFC2821]: 276 o Local-part (implementation warning: this permits quoted strings) 278 o Domain (implementation warning: this permits address-literals) 280 o sub-domain 282 The following definitions are imported from [RFC2822]: 284 o WSP (space or tab) 286 o FWS (folding white space) 287 o field-name (name of a header field) 289 Other tokens not defined herein are imported from [RFC4234]. These 290 are mostly intuitive primitives such as SP, ALPHA, CRLF, etc. 292 3. Protocol Elements 294 Protocol Elements are conceptual parts of the protocol that are not 295 specific to either signers or verifiers. The protocol descriptions 296 for signers and verifiers are described in later sections. 298 3.1 Selectors 300 To support multiple concurrent public keys per signing domain, the 301 key namespace is subdivided using "selectors". For example, 302 selectors might indicate the names of office locations (e.g., 303 "sanfrancisco", "coolumbeach", and "reykjavik"), the signing date 304 (e.g., "january2005", "february2005", etc.), or even the individual 305 user. 307 INFORMATIVE IMPLEMENTERS' NOTE: reusing a selector with a new key 308 (for example, changing the key associated with a user's name) 309 makes it impossible to tell the difference between a message that 310 didn't verify because the key is no longer valid versus a message 311 that is actually forged. Signers SHOULD NOT change the key 312 associated with a selector. When creating a new key, signers 313 SHOULD associate it with a new selector. 315 Selectors are needed to support some important use cases. For 316 example: 318 o Domains which want to delegate signing capability for a specific 319 address for a given duration to a partner, such as an advertising 320 provider or other outsourced function. 322 o Domains which want to allow frequent travelers to send messages 323 locally without the need to connect with a particular MSA. 325 o "Affinity" domains (e.g., college alumni associations) which 326 provide forwarding of incoming mail but which do not operate a 327 mail submission agent for outgoing mail. 329 Periods are allowed in selectors and are component separators. If 330 keys are stored in DNS, the period defines sub-domain boundaries. 331 Sub-selectors might be used to combine dates with locations; for 332 example, "march2005.reykjavik". This can be used to allow delegation 333 of a portion of the selector name-space. 335 ABNF: 336 selector = sub-domain *( "." sub-domain ) 338 The number of public keys and corresponding selectors for each domain 339 are determined by the domain owner. Many domain owners will be 340 satisfied with just one selector whereas administratively distributed 341 organizations may choose to manage disparate selectors and key pairs 342 in different regions or on different email servers. 344 Beyond administrative convenience, selectors make it possible to 345 seamlessly replace public keys on a routine basis. If a domain 346 wishes to change from using a public key associated with selector 347 "january2005" to a public key associated with selector 348 "february2005", it merely makes sure that both public keys are 349 advertised in the public-key repository concurrently for the 350 transition period during which email may be in transit prior to 351 verification. At the start of the transition period, the outbound 352 email servers are configured to sign with the "february2005" private- 353 key. At the end of the transition period, the "january2005" public 354 key is removed from the public-key repository. 356 While some domains may wish to make selector values well known, 357 others will want to take care not to allocate selector names in a way 358 that allows harvesting of data by outside parties. E.g., if per-user 359 keys are issued, the domain owner will need to make the decision as 360 to whether to make this selector associated directly with the user 361 name, or make it some unassociated random value, such as the 362 fingerprint of the public key. 364 3.2 Tag=Value Format for DKIM header fields 366 DKIM uses a simple "tag=value" syntax in several contexts, including 367 in messages, domain signature records, and policy records. 369 Values are a series of strings containing either base64 text, plain 370 text, or quoted printable text, as defined in [RFC2045], section 6.7. 371 The name of the tag will determine the encoding of each value. 373 Formally, the syntax rules are: 374 tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] 375 tag-spec = [FWS] tag-name [FWS] ?=? [FWS] tag-value [FWS] 376 tag-name = ALPHA 0*ALNUMPUNC 377 tag-value = *VALCHAR ; SWSP prohibited at beginning and end 378 VALCHAR = %9 / %d32 - %d58 / %d60 - %d126 379 ; HTAB and SP to TILDE except SEMICOLON 380 ALNUMPUNC = ALPHA / DIGIT / "-" 381 ; alphanumeric plus hyphen. 383 Note that WSP is allowed anywhere around tags; in particular, WSP 384 between the tag-name and the "=", and any WSP before the terminating 385 ";" is not part of the value. 387 Tags MUST be interpreted in a case-sensitive manner. Values MUST be 388 processed as case sensitive unless the specific tag description of 389 semantics specifies case insensitivity. 391 Duplicate tags MUST NOT be specified within a single tag-list. 393 Whitespace within a value MUST be retained unless explicitly excluded 394 by the specific tag description. 396 Tag=value pairs that represent the default value MAY be included to 397 aid legibility. 399 Unrecognized tags MUST be ignored. 401 Tags that have an empty value are not the same as omitted tags. An 402 omitted tag is treated as having the default value; a tag with an 403 empty value explicitly designates the empty string as the value. For 404 example, "g=" does not mean "g=*", even though "g=*" is the default 405 for that tag. 407 3.3 Signing and Verification Algorithms 409 DKIM supports multiple key signing/verification algorithms. The only 410 algorithm defined by this specification at this time is rsa-sha1, 411 which is the default if no algorithm is specified and which MUST be 412 supported by all implementations. 414 3.3.1 The rsa-sha1 Signing Algorithm 416 The rsa-sha1 Signing Algorithm computes a SHA-1 hash of the message 417 header field and body as described in section Section 3.8 below. 418 That hash is then encrypted by the signer using the RSA algorithm 419 (actually PKCS#1 version 1.5 [RFC3447]) and the signer's private key. 420 The hash MUST NOT be truncated or converted into any form other than 421 the native binary form before being signed. 423 More formally, the algorithm for the signature using rsa-sha1 is: 425 RSA(SHA1(canon_message || DKIM-SIG), key) 427 where canon_message is the canonicalized message header and body as 428 defined in Section 3.4 and DKIM-SIG is the canonicalized DKIM- 429 Signature header field sans the signature value itself. 431 3.3.2 Other algorithms 433 Other algorithms MAY be defined in the future. Verifiers MUST ignore 434 any signatures using algorithms that they do not understand. 436 3.3.3 Key sizes 438 Selecting appropriate key sizes is a trade-off between cost, 439 performance and risk. All implementations MUST support keys of sizes 440 512, 768, 1024, 1536 and 2048 bits and MAY support larger keys. 442 Factors that should influence the key size choice include: 444 o The practical constraint that a 2048 bit key is the largest key 445 that fits within a 512 byte DNS UDP response packet 447 o The security constraint that keys smaller than 1024 bits are 448 subject to brute force attacks. 450 o Larger keys impose higher CPU costs to verify and sign email 452 o Keys can be replaced on a regular basis, thus their lifetime can 453 be relatively short 455 o The security goals of this specification are modest compared to 456 typical goals of public-key systems 458 3.4 Canonicalization 460 Empirical evidence demonstrates that some mail servers and relay 461 systems modify email in transit, potentially invalidating a 462 signature. There are two competing perspectives on such 463 modifications. For most signers, mild modification of email is 464 immaterial to the authentication status of the email. For such 465 signers a canonicalization algorithm that survives modest in-transit 466 modification is preferred. 468 Other signers however, demand that any modification of the email -- 469 however minor -- results in an authentication failure. These signers 470 prefer a canonicalization algorithm that does not tolerate in-transit 471 modification of the signed email. 473 Some signers may be willing to accept modifications to headers that 474 are within the bounds of email standards such as [RFC2822], but are 475 unwilling to accept any modification to the body of messages. 477 To satisfy all requirements, two canonicalization algorithms are 478 defined for each of the header and the body: a "simple" algorithm 479 that tolerates almost no modification and a "relaxed" algorithm that 480 tolerates common modifications such as white-space replacement and 481 header field line re-wrapping. A signer MAY specify either algorithm 482 for header or body when signing an email. If no canonicalization 483 algorithm is specified by the signer, the "simple" algorithm is used 484 for both header and body. A verifier MUST be able to process email 485 using either canonicalization algorithm. Further canonicalization 486 algorithms MAY be defined in the future; verifiers MUST ignore any 487 signatures that use unrecognized canonicalization algorithms. 489 In all cases, the header fields of the message are presented to the 490 signing algorithm first in the order indicated by the signature 491 header field and canonicalized using the indicated algorithm. Only 492 header fields listed as signed in the signature header field are 493 included. The CRLF separating the header field from the body is then 494 presented, followed by the canonicalized body. Note that the header 495 and body may use different canonicalization algorithms. 497 Canonicalization simply prepares the email for presentation to the 498 signing or verification algorithm. It MUST NOT change the 499 transmitted data in any way. Canonicalization of header fields and 500 body are described below. 502 3.4.1 The "simple" Header Field Canonicalization Algorithm 504 The "simple" header field canonicalization algorithm does not change 505 the header field in any way. Header fields MUST be presented to the 506 signing or verification algorithm exactly as they are in the message 507 being signed or verified. In particular, header names MUST NOT be 508 case folded. 510 3.4.2 The "relaxed" Header Field Canonicalization Algorithm 512 The "relaxed" header field canonicalization algorithm should apply 513 the following steps in order: 515 o Convert all header field names (not the header field values) to 516 lower case. For example, convert "SUBJect: AbC" to "subject: 517 AbC". 519 o Unwrap all header field continuation lines as described in 520 [RFC2822]; in particular, line terminators embedded in continued 521 header field values (that is, CRLF sequences followed by WSP) MUST 522 be interpreted without the CRLF. Implementations MUST NOT remove 523 the CRLF at the end of the header field value. 525 o Convert all sequences of one or more WSP characters to a single SP 526 character. WSP characters here include those before and after a 527 line wrapping boundary. 529 o Delete all WSP characters at the end of each unwrapped header 530 field value. 532 o Delete any WSP character remaining after the colon separating the 533 header field name from the header field value. The colon 534 separator MUST be retained. 536 [NON-NORMATIVE DOCUMENTATION NOTE: The only difference between 537 "relaxed" header field canonicalization and "nowsp" listed in the 538 previous version of this draft is that nowsp reduces all strings 539 of white space to zero characters while "relaxed" reduces strings 540 of white space to one space.] 542 3.4.3 The "simple" Body Canonicalization Algorithm 544 The "simple" body canonicalization algorithm ignores all empty lines 545 at the end of the message body. An empty line is a line of zero 546 length after removal of the line terminator. It makes no other 547 changes to the message body. 549 3.4.4 The "relaxed" Body Canonicalization Algorithm 551 [[This section may be deleted; see discussion below.]] The "relaxed" 552 body canonicalization algorithm: 554 o Ignores all white space at the end of lines. 556 o Reduces all sequences of WSP within a line to a single SP 557 character. 559 o Ignores all empty lines at the end of the message body. "Empty 560 line" is defined in Section 3.4.3. 562 NON-NORMATIVE DISCUSSION: The authors are undecided whether to 563 leave the "relaxed" body canonicalization algorithm in to the 564 specification or delete it entirely. We believe that for the vast 565 majority of cases, the "simple" body canonicalization algorithm 566 should be sufficient. We simply do not have enough data to know 567 whether retain the "relaxed" body canonicalization algorithm or 568 not. 570 3.4.5 Body Length Limits 572 A body length count MAY be specified to limit the signature 573 calculation to an initial prefix of the body text. If the body 574 length count is not specified then the entire message body is signed 575 and verified. 577 INFORMATIVE IMPLEMENTATION NOTE: The l= tag could be useful in 578 increasing signature robustness when sending to a mailing list 579 that both appends to content sent to it and does not sign its 580 messages. However, using the l= tag enables an attack in which a 581 sender with malicious intent modifies a message to include content 582 that solely benefits the attacker. It is possible for the 583 appended content to completely replace the original content in the 584 end recipient's eyes and to defeat duplicate message detection 585 algorithms. To avoid this attack, signers should be wary of using 586 this tag, and verifiers might wish to ignore the tag or remove 587 text that appears after the specified content length. 589 The body length count allows the signer of a message to permit data 590 to be appended to the end of the body of a signed message. The body 591 length count is made following the canonicalization algorithm; for 592 example, any white space ignored by a canonicalization algorithm is 593 not included as part of the body length count. 595 INFORMATIVE RATIONALE: This capability is provided because it is 596 very common for mailing lists to add trailers to messages (e.g., 597 instructions how to get off the list). Until those messages are 598 also signed, the body length count is a useful tool for the 599 verifier since it MAY as a matter of policy accept messages having 600 valid signatures with extraneous data. 602 Signers of MIME messages that include a body length count SHOULD be 603 sure that the length extends to the closing MIME boundary string. 605 INFORMATIVE IMPLEMENTATION NOTE: A signer wishing to ensure that 606 the only acceptable modifications are to add to the MIME postlude 607 would use a body length count encompassing the entire final MIME 608 boundary string, including the final "--CRLF". A signer wishing 609 to allow additional MIME parts but not modification of existing 610 parts would use a body length count extending through the final 611 MIME boundary string, omitting the final "--CRLF". 613 A body length count of zero means that the body is completely 614 unsigned. 616 Note that verifiers MAY choose to reject or truncate messages that 617 have body content beyond that specified by the body length count. 619 INFORMATIVE IMPLEMENTATION ADVICE: Signers wishing to ensure that 620 no modification of any sort can occur SHOULD specify the "simple" 621 algorthm and no body length count. 623 Despite the measures described above, some messages, particularly 624 those containing 8-bit data, could be subject to modification in 625 transit invalidating the signature. Messages containing 8-bit data 626 SHOULD be converted to MIME format prior to signing, using a suitable 627 content transfer-encoding such as quoted-printable or base64. Such 628 conversion is outside the scope of DKIM; the actual message SHOULD be 629 converted to 7-bit MIME by an MUA or MSA prior to presentation to the 630 DKIM algorithm. 632 3.4.6 Example 634 Assuming a "c=relaxed/relaxed" canonification algorithm, 636 INFORMATIVE EXAMPLE: A message reading: 638 A: X 639 B: Y 640 Z 641 642 C 643 D E 645 when canonicalized using "relaxed" for both header and body 646 results in: 648 a:X 649 b:YZ 650 651 C 652 DE 654 3.5 The DKIM-Signature header field 656 The signature of the email is stored in the "DKIM-Signature:" header 657 field. This header field contains all of the signature and key- 658 fetching data. The DKIM-Signature value is a tag-list as described 659 in Section 3.2. 661 The "DKIM-Signature:" header field SHOULD be treated as though it 662 were a trace header field as defined in section 3.6 of [RFC2822], and 663 hence SHOULD NOT be reordered and SHOULD be kept in blocks prepended 664 to the message. In particular, the "DKIM-Signature" header field 665 SHOULD precede the original email header fields presented to the 666 canonicalization and signature algorithms. 668 The "DKIM-Signature:" header field is included in the signature 669 calculation, after the body of the message; however, when calculating 670 or verifying the signature, the b= (signature value) value MUST be 671 treated as though it were the null string. Unknown tags MUST be 672 signed but MUST be otherwise ignored by verifiers. 674 The encodings for each field type are listed below. Tags described 675 as quoted-printable are as described in section 6.7 of [RFC2045], 676 with the additional conversion of semicolon and vertical bar 677 characters to =3B and =7C, respectively. 679 Tags on the DKIM-Signature header field along with their type and 680 requirement status are shown below. Valid tags are: 682 v= Version (MUST NOT be included). This tag is reserved for future 683 use to indicate a possible new, incompatible version of the 684 specification. It MUST NOT be included in the DKIM-Signature 685 header field. 687 a= The algorithm used to generate the signature (plain-text; 688 REQUIRED). Signers and verifiers MUST support "rsa-sha1", an RSA- 689 signed SHA-1 digest. See Section 3.3 for a description of 690 algorithms. 692 INFORMATIVE RATIONALE: The authors understand that SHA-1 has 693 been theoretically compromised. However, viable attacks 694 require the attacker to choose both sets of input text; given a 695 preexisting input (a "preimaging" attack), it is still hard to 696 determine another input that produces an SHA-1 collision, and 697 the chance that such input would be of value to an attacker is 698 minimal. Also, there is broad library for SHA-1, whereas 699 alternatives such as SHA-256 are just emerging. Finally, DKIM 700 is not intended to have legal- or military-grade requirements. 701 There is nothing inherent in using SHA-1 here other than 702 implementer convenience. See 703 for 704 a discussion of the security issues. 706 b= The signature data (base64; REQUIRED). Whitespace is ignored in 707 this value and MUST be ignored when re-assembling the original 708 signature. This is another way of saying that the signing process 709 can safely insert FWS in this value in arbitrary places to conform 710 to line-length limits. See section Section 5 for how the 711 signature is computed. 713 c= Body canonicalization (plain-text; OPTIONAL, default is "simple/ 714 simple"). This tag informs the verifier of the type of 715 canonicalization used to prepare the message for signing. It 716 consists of two names separated by a "slash" (%d47) character, 717 corresponding to the header and body canonicalization algorithms 718 respectively. These algorithms are described in section 719 Section 3.4. If only one algorithm is named, that algorithm is 720 used for the header and "simple" is used for the body. For 721 example, "relaxed" is treated the same as "relaxed/simple". 723 d= The domain of the signing entity (plain-text; REQUIRED). This 724 is the domain that will be queried for the public key. This 725 domain MUST be the same as or a parent domain of the "i=" tag. 726 When presented with a signature that does not meet this 727 requirement, verifiers MUST either ignore the signature or reject 728 the message.. 730 h= Signed header fields (plain-text, but see description; 731 REQUIRED). A colon-separated list of header field names that 732 identify the header fields presented to the signing algorithm. 733 The field MUST contain the complete list of header fields in the 734 order presented to the signing algorithm. The field MAY contain 735 names of header fields that do not exist when signed; nonexistent 736 header fields do not contribute to the signature computation (that 737 is, they are treated as the null input, including the header field 738 name, the separating colon, the header field value, and any CRLF 739 terminator), and when verified non-existent header fields MUST be 740 treated in the same way. The field MUST NOT include the DKIM- 741 Signature header field that is being created or verified. Folding 742 white space (FWS) MAY be included on either side of the colon 743 separator. Header field names MUST be compared against actual 744 header field names in a case insensitive manner. 746 ABNF: 748 sig-h-tag = "h=" *FWS hdr-name 0*( *FWS ":" *FWS hdr-name ) 749 hdr-name = field-name 751 INFORMATIVE EXPLANATION: By "signing" header fields that do 752 not actually exist, a signer can prevent insertion of those 753 header fields before verification. However, since a sender 754 cannot possibly know what header fields might be created in the 755 future, and that some MUAs might present header fields that are 756 embedded inside a message (e.g., as a message/rfc822 content 757 type), the security of this solution is not total. 759 INFORMATIVE EXPLANATION: The exclusion of the header field 760 name and colon as well as the header field value for non- 761 existent header fields prevents an attacker from inserting an 762 actual header field with a null value. 764 i= Identity of the user or agent (e.g., a mailing list manager) on 765 behalf of which this message is signed (quoted-printable; 766 OPTIONAL, default is an empty local-part followed by an "@" 767 followed by the domain from the "d=" tag). The syntax is a 768 standard email address where the local-part is optional. If the 769 signing domain is unable or unwilling to commit to an individual 770 user name within their domain, the local-part of the address MUST 771 be omitted. If the local-part of the address is omitted or the 772 "i=" tag is not present, the key used to sign MUST be valid for 773 any address in the domain. The domain part of the address MUST be 774 the same as or a subdomain of the value of the "d=" tag. 776 ABNF: 778 sig-i-tag = "i=" [ Local-part ] "@" Domain 780 INFORMATIVE DISCUSSION: This document does not require the 781 value of the "i=" tag to match the identity in any message 782 header field fields. This is considered to be a verifier 783 policy issue, described in another document [XREF-TBD]. 784 Constraints between the value of the "i=" tag and other 785 identities in other header fields seek to apply basic 786 authentication into the semantics of trust associated with a 787 role such as content author. Trust is a broad and complex 788 topic and trust mechanisms are subject to highly creative 789 attacks. The real-world efficacy of any but the most basic 790 bindings between the "i=" value and other identities is not 791 well established, nor is its vulnerability to subversion by an 792 attacker. Hence reliance on the use of these options SHOULD be 793 strictly limited. In particular it is not at all clear to what 794 extent a typical end-user recipient can rely on any assurances 795 that might be made by successful use of the "i=" options. 797 l= Body count (plain-text decimal integer; OPTIONAL, default is 798 entire body). This tag informs the verifier of the number of 799 bytes in the body of the email included in the cryptographic hash, 800 starting from 0 immediately following the CRLF preceding the body. 802 INFORMATIVE IMPLEMENTATION WARNING: Use of the l= tag might 803 allow display of fraudulent content without appropriate warning 804 to end users. The l= tag is intended for increasing signature 805 robustness when sending to mailing lists that both modify their 806 content and do not sign their messages. However, using the l= 807 tag enables man-in-the-middle attacks in which an intermediary 808 with malicious intent modifies a message to include content 809 that solely benefits the attacker. It is possible for the 810 appended content to completely replace the original content in 811 the end recipient's eyes and to defeat duplicate message 812 detection algorithms. Examples are described in Security 813 Considerations Section 9. 815 To avoid this attack, signers should be extremely wary of using 816 this tag, and verifiers might wish to ignore the tag or remove 817 text that appears after the specified content length. 819 q= A colon-separated list of query methods used to retrieve the 820 public key (plain-text; OPTIONAL, default is "dns"). Each query 821 method is of the form "type[/options]", where the syntax and 822 semantics of the options depends on the type. If there are 823 multiple query mechanisms listed, the choice of query mechanism 824 MUST NOT change the interpretation of the signature. Currently 825 the only valid value is "dns" which defines the DNS lookup 826 algorithm described elsewhere in this document. No options are 827 defined for the "dns" query type, but the string "dns" MAY have a 828 trailing "/" character. Verifiers and signers MUST support "dns". 830 INFORMATIVE RATIONALE: Explicitly allowing a trailing "/" on 831 "dns" allows for the possibility of adding options later and 832 makes it clear that matching of the query type must terminate 833 on either "/" or end of string. 835 s= The selector subdividing the namespace for the "d=" (domain) tag 836 (plain-text; REQUIRED). 838 t= Signature Timestamp (plain-text; RECOMMENDED, default is an 839 unknown creation time). The time that this signature was created. 840 The format is the standard Unix seconds-since-1970. The value is 841 expressed as an unsigned integer in decimal ASCII. 843 INFORMATIVE IMPLEMENTATION NOTE: This value is not constrained 844 to fit into a 31- or 32-bit integer. Implementations SHOULD be 845 prepared to handle values up to at least 10^12 (until 846 approximately AD 200,000; this fits into 40 bits). To avoid 847 denial of service attacks, implementations MAY consider any 848 value longer than 12 digits to be infinite. 850 x= Signature Expiration (plain-text; RECOMMENDED, default is no 851 expiration). Signature expiration in seconds-since-1970 format as 852 an absolute date, not as a time delta from the signing timestamp. 853 Signatures MUST NOT be considered valid if the current time at the 854 verifier is past the expiration date. The value is expressed as 855 an unsigned integer in decimal ASCII. 857 INFORMATIVE IMPLEMENTATION NOTE: See above. 859 INFORMATIVE NOTE: The x= tag is not intended as an anti-replay 860 defense. 862 z= Copied header fields (plain-text, but see description; OPTIONAL, 863 default is null). A vertical-bar-separated list of header field 864 names and copies of header field values that identify the header 865 fields presented to the signing algorithm. The field MUST contain 866 the complete list of header fields in the order presented to the 867 signing algorithm. Copied header field values MUST immediately 868 follow the header field name with a colon separator (no white 869 space permitted). Header field values MUST be represented as 870 Quoted-Printable [RFC2045] with vertical bars, colons, semicolons, 871 and white space encoded in addition to the usual requirements. 873 Verifiers MUST NOT use the copied header field values for 874 verification should they be present in the h= field. Copied 875 header field values are for forensic use only. 877 Header fields with characters requiring conversion (perhaps from 878 legacy MTAs which are not [RFC2822] compliant) SHOULD be converted 879 as described in [RFC2047]. 881 ABNF: 883 sig-z-tag = "z=" *FWS hdr-copy *( *FWS "|" hdr-copy ) 884 *FWS 888 ; needs to be updated with real definition 889 ; (could be messy) 891 INFORMATIVE EXAMPLE of a signature header field spread across 892 multiple continuation lines: 894 DKIM-Signature: a=rsa-sha1; d=example.net; s=brisbane 895 c=simple; q=dns; i=@eng.example.net; t=1117574938; x=1118006938; 896 h=from:to:subject:date; 897 z=From:foo@eng.example.net|To:joe@example.com| 898 Subject:demo%20run|Date:July%205,%202005%203:44:08%20PM%20-0700 899 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ 900 VoG4ZHRNiYzR 902 3.6 The Authentication-Results header field 904 Verifiers wishing to communicate the results of verification via an 905 email header field SHOULD use the Authentication-Results header field 906 [ID-AUTH-RES]. 908 3.7 Key Management and Representation 910 DKIM keys do not require third party signatures by Certificate 911 Authorities in order to be trusted, since the public key is retrieved 912 directly from the signer. 914 DKIM keys can potentially be stored in multiple types of key servers 915 and in multiple formats. The storage and format of keys are 916 irrelevant to the remainder of the DKIM algorithm. 918 Parameters to the key lookup algorithm are the domain of the 919 responsible signer (the "d=" tag of the DKIM-Signature header field), 920 the selector (the "s=" tag), and the signing identity (the "i=" tag). 921 The "i=" tag value could be ignored by some key services. 923 This document defines a single binding, using DNS to distribute the 924 keys. 926 3.7.1 Textual Representation 928 It is expected that many key servers will choose to present the keys 929 in a text format. The following definition MUST be used for any DKIM 930 key represented in textual form. 932 The overall syntax is a key-value-list as described above. The 933 current valid tags are: 935 v= Version of the DKIM key record (plain-text; RECOMMENDED, default 936 is "DKIM1"). If specified, this tag MUST be set to "DKIM1" 937 (without the quotes). This tag MUST be the first tag in the 938 response. Responses beginning with a "v=" tag with any other 939 value MUST be discarded. 941 g= granularity of the key (plain-text; OPTIONAL, default is "*"). 942 This value MUST match the local part of the signing address, with 943 a "*" character acting as a wildcard. The intent of this tag is 944 to constrain which signing address can legitimately use this 945 selector. An email with a signing address that does not match the 946 value of this tag constitutes a failed verification. Wildcarding 947 allows matching for addresses such as "user+*". An empty "g=" 948 value never matches any addresses. 950 h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to 951 allowing all algorithms). A colon-separated list of hash 952 algorithms that might be used. Signers and Verifiers MUST support 953 the "sha1" hash algorithm. 955 k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and 956 verifiers MUST support the 'rsa' key type, as defined in [RFC3447] 958 n= Notes that might be of interest to a human (quoted-printable; 959 OPTIONAL, default is empty). No interpretation is made by any 960 program. This tag should be used sparingly in any key server 961 mechanism that has space limitations (notably DNS). 963 p= Public-key data (base64; REQUIRED). An empty value means that 964 this public key has been revoked. The syntax and semantics of 965 this tag value is defined by the k= tag. 967 s= Service Type (plain-text; OPTIONAL; default is "*"). A colon- 968 separated list of service types to which this record applies. 969 Verifiers for a given service type MUST ignore this record if the 970 appropriate type is not listed. Currently defined service types 971 are: 973 * matches all service types 975 email electronic mail (not necessarily limited to SMTP) 977 This tag is intended to permit senders to constrain the use of 978 delegated keys, e.g., where a company is willing to delegate the 979 right to send mail in their name to an outsourcer, but not to send 980 IM or make VoIP calls. (This of course presumes that these keys 981 are used in other services in the future.) 983 t= Flags, represented as a colon-separated list of names (plain- 984 text; OPTIONAL, default is no flags set). The defined flags are: 986 y This domain is testing DKIM; unverified email MUST NOT be 987 treated differently from verified email. Verifier systems MAY 988 wish to track testing mode results to assist the signer. 990 Unrecognized flags MUST be ignored. 992 3.7.2 DNS binding 994 A binding using DNS as a key service is hereby defined. All 995 implementations MUST support this binding. 997 3.7.2.1 Name Space. 999 All DKIM keys are stored in a "_domainkey" subdomain. Given a DKIM- 1000 Signature field with a "d=" tag of "domain" and an "s=" tag of 1001 "selector", the DNS query will be for "selector._domainkey.domain". 1003 The value of the "i=" tag is not used by the DNS binding. 1005 3.7.2.2 Resource Record Types for Key Storage 1007 This section needs to be fleshed out. ACTUALLY: will be addressed 1008 in another document. 1010 Two RR types are used: DKK and TXT. 1012 The DKK RR is expected to be a non-text, binary representation 1013 intended to allow the largest possible keys to be represented and 1014 transmitted in a UDP DNS packet. Details of this RR are described in 1015 [ID-DKIM-RR]. 1017 TXT records are encoded as described in section Section 3.7.1 above. 1019 Verifiers SHOULD search for a DKIM RR first, if possible, followed by 1020 a TXT RR. If the verifier is unable to search for a DKK RR or a DKK 1021 RR is not found, the verifier MUST search for a TXT RR. 1023 3.8 Computing the Message Hash 1025 Both signing and verifying message signatures starts with a step of 1026 computing a cryptographic hash of the message. Signers will choose 1027 the parameters of the signature as described in Section 5; verifiers 1028 will use the parameters specified in the "DKIM-Signature" header 1029 being verified. In the following discussion, the names of the tags 1030 in the "DKIM-Signature" header which either exists (when verifying) 1031 or will be created (when signing) are used. 1033 The signer or verifier passes the following to the hash algorithm in 1034 the indicated order. Note that canonicalization (described in 1035 Section 3.4) is only used to prepare the email for signing or 1036 verifying; it does not affect the transmitted email in any way. 1038 1. The header fields chosen in as specified by the "h=" tag, in the 1039 order specified in that tag, and canonicalized using the header 1040 canonicalization algorithm specified in the "c=" tag. 1042 2. A single CRLF. 1044 3. The message body, canonicalized using the body canonicalization 1045 algorithm specified in the "c=" tag, and truncated to the length 1046 specified in the "l=" tag. 1048 4. A single CRLF. 1050 5. The "DKIM-Signature" header field that exists (verifying) or will 1051 be inserted (signing) in the message, with the content of the 1052 "b=" tag deleted (i.e., treated as the empty string), 1053 canonicalized using the header canonicalization algorithm 1054 specified in the "c=" tag, and without a trailing CRLF. 1056 After the body is processed, a single CRLF followed by the "DKIM- 1057 Signature" header field being created or verified is presented to the 1058 algorithm. The value portion of the "b=" tag (that is, the portion 1059 after the "=" sign) must be treated as though it were empty, and the 1060 header field must be canonicalized according to the algorithm that is 1061 specified in the "c=" tag. Any final CRLF on the "DKIM-Signature" 1062 header field MUST NOT be included in the signature computation. 1064 All tags and their values in the DKIM-Signature header field are 1065 included in the cryptographic hash with the sole exception of the 1066 value portion of the "b=" (signature) tag, which MUST be treated as 1067 the null string. All tags MUST be included even if they might not be 1068 understood by the verifier. The header field MUST be presented to 1069 the hash algorithm after the body of the message rather than with the 1070 rest of the header fields and MUST be canonicalized as specified in 1071 the "c=" (canonicalization) tag. The DKIM-Signature header field 1072 MUST NOT be included in its own h= tag. 1074 When calculating the hash on values that will be transmitted using 1075 base64 or quoted-printable encoding, signers MUST compute the hash 1076 after the encoding. Likewise, the verifier MUST incorporate the 1077 values into the hash before decoding the base64 or quoted-printable 1078 text. However, the hash MUST be computed before transport level 1079 encodings such as SMTP "dot-stuffing." 1080 With the exception of the canonicalization procedure described in 1081 section Section 3.4, the DKIM signing process treats the body of 1082 messages as simply a string of characters. DKIM messages MAY be 1083 either in plain-text or in MIME format; no special treatment is 1084 afforded to MIME content. Message attachments in MIME format MUST be 1085 included in the content which is signed. 1087 4. Semantics of Multiple Signatures 1089 Considerable energy has been spent discussing the desirability and 1090 semantics of multiple DKIM signatures in a single message, 1091 particularly in a "re-sending" scenario such as a mailing list. On 1092 the one hand, discarding existing signature header fields loses 1093 information which could prove to be valuable in the future. On the 1094 other hand, since header fields are known to be re-ordered in transit 1095 by at least some MTAs, determining the most interesting signature 1096 header field is non-trivial. 1098 Further confusion could occur with multiple signatures added at the 1099 same logical "depth". For example, a signer could choose to sign 1100 using different signing or canonicalization algorithms. There is no 1101 a priori way to determine that two signatures are alternatives versus 1102 nested in a re-sending scenario. 1104 Also, many agents are expected to break existing signatures (e.g., a 1105 mailing list that modifies Subject header fields or adds unsubscribe 1106 information to the end of the message). Retaining signature 1107 information that is known to be bad could create more problems than 1108 it solves. 1110 For these reasons, multiple signatures are not prohibited but are 1111 left undefined. 1113 INFORMATIVE IMPLEMENTATION GUIDANCE: Agents that forward mail 1114 without modification could decide whether to add another signature 1115 or simply retain an existing signatures. Agents that are known to 1116 break existing signatures MAY leave the existing signature or 1117 delete it. Agents that re-sign messages that are already signed 1118 SHOULD verify the previous signature and should probably refuse to 1119 sign any critical information that failed a signature 1120 verification. 1122 5. Signer Actions 1124 5.1 Determine if the Email Should be Signed and by Whom 1126 A signer can obviously only sign email for domains for which it has a 1127 private-key and the necessary knowledge of the corresponding public 1128 key and selector information. However there are a number of other 1129 reasons beyond the lack of a private key why a signer could choose 1130 not to sign an email. 1132 A SUBMISSION server MAY sign if the sender is authenticated by some 1133 secure means, e.g., SMTP AUTH. Within a trusted enclave the signing 1134 address MAY be derived from the header field according to local 1135 signer policy. Within a trusted enclave an MTA MAY do the signing. 1137 INFORMATIVE IMPLEMENTER ADVICE: SUBMISSION servers should not 1138 sign Received header fields if the outgoing gateway MTA obfuscates 1139 Received header fields, for example to hide the details of 1140 internal topology. 1142 A signer MUST NOT sign an email if it is unwilling to be held 1143 responsible for the message; in particular, the signer SHOULD ensure 1144 that the submitter has a bona fide relationship with the signer and 1145 that the submitter has the right to use the address being claimed. 1147 A signer SHOULD NOT remove an existing "DKIM-Signature:" header field 1148 unless that signature was added by an entity under the same domain. 1149 That is, DKIM-Signature header fields SHOULD NOT be removed unless 1150 the d= tag of that existing DKIM-Signature header field is the same 1151 as or a subdomain of the d= tag of the new DKIM-Signature header 1152 field that is being added. 1154 If an email cannot be signed for some reason, it is a local policy 1155 decision as to what to do with that email. 1157 5.2 Select a private-key and corresponding selector information 1159 This specification does not define the basis by which a signer should 1160 choose which private-key and selector information to use. Currently, 1161 all selectors are equal as far as this specification is concerned, so 1162 the decision should largely be a matter of administrative 1163 convenience. 1165 A signer SHOULD NOT sign with a key that is expected to expire within 1166 seven days; that is, when rotating to a new key, signing should 1167 immediately commence with the new key and the old key SHOULD be 1168 retained for at least seven days before being removed from the key 1169 server. 1171 5.3 Normalize the Message to Prevent Transport Conversions 1173 Some messages, notably those using 8-bit characters, are subject to 1174 conversion to 7-bit during transmission. Such conversions will break 1175 DKIM signatures. In order to minimize the chances of such breakage, 1176 signers SHOULD convert the message to MIME-encoded 7-bit form as 1177 described in [RFC2045] before signing. 1179 Should the message be submitted to the signer with any local encoding 1180 that will be modified before transmission, such conversion to 1181 canonical form MUST be done before signing. In particular, some 1182 systems use local line separator conventions (such as the Unix 1183 newline character) internally rather than the SMTP-standard CRLF 1184 sequence. All such local conventions MUST be converted to canonical 1185 format before signing. 1187 More generally, the signer MUST sign the message as it will be 1188 emitted on the wire rather than in some local or internal form. 1190 5.4 Determine the header fields to Sign 1192 The From header field MUST be signed (that is, included in the h= tag 1193 of the resulting DKIM-Signature header field); any header field that 1194 describes the role of the signer (for example, the Sender or Resent- 1195 From header field if the signature is on behalf of the corresponding 1196 address and that address is different from the From address) MUST 1197 also be included. The signed header fields SHOULD also include the 1198 Subject and Date header fields as well as all MIME header fields. 1199 Signers SHOULD NOT sign an existing header field likely to be 1200 legitimately modified or removed in transit. In particular, 1201 [RFC2821] explicitly permits modification or removal of the "Return- 1202 Path" header field in transit. Signers MAY include any other header 1203 fields present at the time of signing at the discretion of the 1204 signer. It is RECOMMENDED that all other existing, non-repeatable 1205 header fields be signed. 1207 The DKIM-Signature header field is always implicitly signed and MUST 1208 NOT be included in the h= tag except to indicate that other 1209 preexisting signatures are also signed. 1211 Signers MUST sign any header fields that the signers wish to have the 1212 verifiers treat as trusted. Put another way, verifiers MAY treat 1213 unsigned header fields with extreme skepticism, up to and including 1214 refusing to display them to the end user. 1216 Signers MAY claim to have signed header fields that do not exist 1217 (that is, signers MAY include the header field name in the h= tag 1218 even if that header field does not exist in the message). When 1219 computing the signature, the non-existing header field MUST be 1220 treated as the null string (including the header field name, header 1221 field value, all punctuation, and the trailing CRLF). 1223 INFORMATIVE RATIONALE: This allows signers to explicitly assert 1224 the absence of a header field; if that header field should be 1225 added later the signature will fail. 1227 Signers choosing to sign an existing replicated header field (such as 1228 Received) MUST sign the physically last instance of that header field 1229 in the header field block. Signers wishing to sign multiple 1230 instances of an existing replicated header field MUST include the 1231 header field name multiple times in the h= tag of the DKIM-Signature 1232 header field, and MUST sign such header fields in order from the 1233 bottom of the header field block to the top. The signer MAY include 1234 more header field names than there are actual corresponding header 1235 fields to indicate that additional header fields of that name SHOULD 1236 NOT be added. (However, header fields that can be replicated should 1237 not be signed; see below.) 1239 INFORMATIVE EXAMPLE: 1241 If the signer wishes to sign two existing Received header fields, 1242 and the existing header contains: then the resulting DKIM- 1243 Signature header field should read: 1245 Received: 1246 Received: 1247 Received: 1249 DKIM-Signature: ... h=Received : Received : ... 1251 and Received header fields and will be signed in that 1252 order. 1254 Signers SHOULD NOT sign header fields that might be replicated 1255 (either at the time of signing or potentially in the future), with 1256 the exception of trace header fields such as Received. Comment and 1257 non standard header fields (including X-* header fields) are 1258 permitted by [RFC2822] to be replicated; however, many such header 1259 fields are, by convention, not replicated. Signers need to 1260 understand the implications of signing header field fields that might 1261 later be replicated, especially in the face of header field 1262 reordering. In particular, [RFC2822] only requires that trace header 1263 fields retain the original order. 1265 INFORMATIVE RATIONALE: Received: is allowed because these header 1266 fields, as well as Resent-* header fields, are already order- 1267 sensitive. 1269 INFORMATIVE ADMONITION: Despite the fact that [RFC2822] permits 1270 header field blocks to be reordered (with the exception of 1271 Received header fields), reordering of signed replicated header 1272 fields by intermediate MTAs will cause DKIM signatures to be 1273 broken; such anti-social behavior should be avoided. 1275 INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this 1276 specification, all end-user visible header fields should be signed 1277 to avoid possible "indirect spamming." For example, if the 1278 "Subject" header field is not signed, a spammer can resend a 1279 previously signed mail, replacing the legitimate subject with a 1280 one-line spam. 1282 INFORMATIVE NOTE: There has been some discussion that a Sender 1283 Signing Policy include the list of header fields that the signer 1284 always signs. N.B. In theory this is unnecessary, since as long 1285 as the signer really always signs the indicated header fields 1286 there is no possibility of an attacker replaying an existing 1287 message that has such an unsigned header field. 1289 5.5 Compute the Message Hash 1291 The signer MUST compute the message hash as described in Section 3.8 1292 and then sign it using the selected public-key algorithm. 1294 To avoid possible ambiguity, a signer SHOULD either sign or remove 1295 any preexisting "Authentication-Results:" header fields from the 1296 email prior to preparation for signing and transmission. 1297 "Authentication-Results" header fields MUST only be signed if the 1298 signer is certain of the authenticity of the preexisting header 1299 field, for example, if it is locally generated or signed by a 1300 previous DKIM-Signature line that the current signer has verified. 1301 Signers MUST NOT sign Authentication-Results header fields that could 1302 be forgeries. 1304 Entities such as mailing list managers that implement DKIM and which 1305 modify the message or the header field (for example, inserting 1306 unsubscribe information) before retransmitting the message SHOULD 1307 check any existing signature on input and MUST make such 1308 modifications before re-signing the message; such signing SHOULD 1309 include the Authentication-Results header field, if any, inserted 1310 upon message receipt. 1312 5.6 Insert the DKIM-Signature header field 1314 The final step in the signing process is that the signer MUST insert 1315 the "DKIM-Signature:" header field prior to transmitting the email. 1316 The "DKIM-Signature" header MUST be the same as used to compute the 1317 hash as described above, except that the value of the "b=" tag MUST 1318 be the appropriately signed hash computed in the previous step, 1319 signed using the algorithm specified in the "a=" tag of the "DKIM- 1320 Signature" header and using the private key corresponding to the 1321 selector given in the "s=" tag of the "DKIM-Signature" header field, 1322 as chosen above in section Section 5.2 1324 The "DKIM-Signature" SHOULD be inserted before any header fields that 1325 it signs in the header field block. 1327 INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this 1328 is to insert the "DKIM-Signature" header field at the beginning of 1329 the header field block. 1331 6. Verifier Actions 1333 6.1 Introduction 1335 Since a signer MAY expire a public key at any time, it is recommended 1336 that verification occur in a timely manner with the most timely place 1337 being during acceptance by the border MTA. 1339 A border or intermediate MTA MAY verify the message signatures and 1340 add a verification header field to incoming messages. This 1341 considerably simplifies things for the user, who can now use an 1342 existing mail user agent. Most MUAs have the ability to filter 1343 messages based on message header fields or content; these filters 1344 would be used to implement whatever policy the user wishes with 1345 respect to unsigned mail. 1347 A verifying MTA MAY implement a policy with respect to unverifiable 1348 mail, regardless of whether or not it applies the verification header 1349 field to signed messages. Separate policies MAY be defined for 1350 unsigned messages, messages with incorrect signatures, and when the 1351 signature cannot be verified. Treatment of unsigned messages MUST be 1352 based on the results of the Sender Signing Policy check described in 1353 [ID-DKIM-SSP]. 1355 6.2 Extract the Signature from the Message 1357 The signature and associated signing identity is included in the 1358 value of the DKIM-Signature header field. 1360 Verifiers MUST ignore DKIM-Signature header fields with a "v=" tag. 1361 Existence of such a tag indicates a new, incompatible version of the 1362 DKIM-Signature header field. 1364 If the "DKIM-Signature" header field does not contain the "i=" tag, 1365 the verifier MUST behave as though the value of that tag were "@d", 1366 where "d" is the value from the "d=" tag (which MUST exist). 1368 Verifiers MUST confirm that the domain specified in the "d=" tag is 1369 the same as or a superdomain of the domain part of the "i=" tag. If 1370 not, the DKIM-Signature header field MUST be ignored. 1372 Implementers MUST meticulously validate the format and values in the 1373 "DKIM-Signature:" header field; any inconsistency or unexpected 1374 values MUST result in an unverified email. Being "liberal in what 1375 you accept" is definitely a bad strategy in this security context. 1376 Note however that this does not include the existence of unknown tags 1377 in a "DKIM-Signature" header field, which are explicitly permitted. 1379 Verifiers MUST NOT attribute ultimate meaning to the order of 1380 multiple DKIM-Signature header fields. In particular, there is 1381 reason to believe that some relays will reorder the header field in 1382 potentially arbitrary ways. 1384 INFORMATIVE IMPLEMENTATION NOTE: Verifiers might use the order as 1385 a clue to signing order in the absence of any other information. 1386 However, other clues as to the semantics of multiple signatures 1387 must be considered before using ordering. 1389 Since there can be multiple signatures in a message, a verifier 1390 SHOULD ignore an invalid signature (regardless if caused by a 1391 syntactic or semantic problem) and try other signatures. A verifier 1392 MAY choose to treat a message with one or more invalid signatures 1393 with more suspicion than a message with no signature at all. 1395 6.3 Get the Public Key 1397 The public key is needed to complete the verification process. The 1398 process of retrieving the public key depends on the query type as 1399 defined by the "q=" tag in the "DKIM-Signature:" header field line. 1400 Obviously, a public key should only be retrieved if the process of 1401 extracting the signature information is completely successful. 1402 Details of key management and representation are described in section 1403 Section 3.7. The verifier MUST validate the key record and MUST 1404 ignore any public key records that are malformed. 1406 When validating a message, a verifier MUST: 1408 1. Retrieve the public key as described under Key Management 1409 (Section 3.7) using the domain from the "d=" tag and the selector 1410 from the "s=" tag. 1412 2. If the query for the public key fails to respond, the verifier 1413 SHOULD defer acceptance of this email (normally this will be 1414 achieved with a 451/4.7.5 SMTP response code). 1416 3. If the query for the public key fails because the corresponding 1417 RR does not exist, the verifier MUST ignore the signature. 1419 4. If the result returned from the query does not adhere to the 1420 format defined in this specification, the verifier MUST ignore 1421 the signature. 1423 5. If the "g=" tag in the public key does not match the local part 1424 of the "i=" tag on the message signature, the verifier MUST treat 1425 the signature as invalid. If the local part of the "i=" tag on 1426 the message signature is not present, the g= tag must be * (valid 1427 for all addresses in the domain) or not present (which defaults 1428 to *), otherwise the verifier MUST ignore the signature. Other 1429 than this test, verifiers MUST NOT treat a message signed with a 1430 key record having a g= tag any differently than one without; in 1431 particular, verifiers MUST NOT prefer messages that seem to have 1432 an individual signature by virtue of a g= tag vs. a domain 1433 signature. 1435 6. If the "h=" tag exists in the public key record and the hash 1436 algorithm implied by the a= tag in the DKIM-Signature header is 1437 not included in the "h=" tag, the verifier MUST ignore the 1438 signature. 1440 7. If the public key data is not suitable for use with the algorithm 1441 type defined by the "a=" tag in the "DKIM-Signature" header 1442 field, the verifier MUST ignore the signature. 1444 If the public key data (the "p=" tag) is empty then this key has been 1445 revoked and the verifier MUST treat this as a failed signature check. 1447 6.4 Compute the Verification 1449 Given a signer and a public key, verifying a signature consists of 1450 the following steps. 1452 o Based on the algorithm defined in the "c=" tag, the body length 1453 specified in the "l=" tag, and the header field names in the "h=" 1454 tag, create a canonicalized copy of the email as is described in 1455 section Section 3.8. When matching header field names in the "h=" 1456 tag against the actual message header field, comparisons MUST be 1457 case-insensitive. 1459 o Based on the algorithm indicated in the "a=" tag, 1461 * Compute the message hash from the canonical copy as described 1462 in section Section 3.8. 1464 * Decrypt the signature using the signer's public key. 1466 o Compare the decrypted signature to the message hash. If they are 1467 identical, the hash computed by the signer must be the same as the 1468 hash computed by the verifier, and hence the two messages are 1469 identical. 1471 INFORMATIVE IMPLEMENTER'S NOTE: Implementations might wish to 1472 initiate the public-key query in parallel with calculating the 1473 hash as the public key is not needed until the final decryption is 1474 calculated. 1476 Verifiers MUST ignore any DKIM-Signature header fields where the 1477 signature does not validate. Verifiers that are prepared to validate 1478 multiple signature header fields SHOULD proceed to the next signature 1479 header field, should it exist. However, verifiers MAY make note of 1480 the fact that an invalid signature was present for consideration at a 1481 later step. 1483 INFORMATIVE NOTE: The rationale of this requirement is to permit 1484 messages that have invalid signatures but also a valid signature 1485 to work. For example, a mailing list exploder might opt to leave 1486 the original submitter signature in place even though the exploder 1487 knows that it is modifying the message in some way that will break 1488 that signature, and the exploder inserts its own signature. In 1489 this case the message should succeed even in the presence of the 1490 known-broken signature. 1492 If a body length is specified in the "l=" tag of the signature, 1493 verifiers MUST only verify the number of bytes indicated in the body 1494 length. Verifiers MAY decide that a message containing bytes beyond 1495 the indicated body length MAY still treat such a message as 1496 suspicious. Verifiers MAY truncate the message at the indicated body 1497 length or reject the message outright. MUAs MAY visually mark the 1498 unverified part of the body in a distinctive font or color to the end 1499 user. 1501 6.5 Apply Sender Signing Policy 1503 Verifiers MUST consult the Sender Signing Policy as described in [ID- 1504 DKIM-SSP] and act accordingly. The range of possibilities is up to 1505 the verifier, but it MAY include rejecting the email. 1507 6.6 Interpret Results/Apply Local Policy 1509 It is beyond the scope of this specification to describe what actions 1510 a verifier system should make, but an authenticated email presents an 1511 opportunity to a receiving system that unauthenticated email cannot. 1512 Specifically, an authenticated email creates a predictable identifier 1513 by which other decisions can reliably be managed, such as trust and 1514 reputation. Conversely, unauthenticated email lacks a reliable 1515 identifier that can be used to assign trust and reputation. It is 1516 reasonable to treat unauthenticated email as lacking any trust and 1517 having no positive reputation. 1519 If the verifying MTA is capable of verifying the public key of the 1520 signer and check the signature on the message synchronously with the 1521 SMTP session and such signature is missing or does not verify the MTA 1522 MAY reject the message with an error such as: 1524 550 5.7.1 Unsigned messages not accepted 1526 550 5.7.5 Message signature incorrect 1528 If it is not possible to fetch the public key, perhaps because the 1529 key server is not available, a temporary failure message MAY be 1530 generated, such as: 1532 451 4.7.5 Unable to verify signature - key server unavailable 1534 Once the signature has been verified, that information MUST be 1535 conveyed to higher level systems (such as explicit allow/white lists 1536 and reputation systems) and/or to the end user. If the 1537 authentication status is to be stored in the message header field, 1538 the Authentication-Results header field [ID-AUTH-RES] SHOULD be used 1539 to convey this information. If the message is signed on behalf of 1540 any address other than that in the From: header field, the mail 1541 system SHOULD take pains to ensure that the actual signing identity 1542 is clear to the reader. 1544 The verifier MAY treat unsigned header fields with extreme 1545 skepticism, including marking them as untrusted or even deleting them 1546 before display to the end user. 1548 While the symptoms of a failed verification are obvious -- the 1549 signature doesn't verify -- establishing the exact cause can be more 1550 difficult. If a selector cannot be found, is that because the 1551 selector has been removed or was the value changed somehow in 1552 transit? If the signature line is missing is that because it was 1553 never there, or was it removed by an over-zealous filter? For 1554 diagnostic purposes, the exact reason why the verification fails 1555 SHOULD be recorded in the "Authentication-Results" header field and 1556 possibly the system logs. However in terms of presentation to the 1557 end user, the result SHOULD be presented as a simple binary result: 1558 either the email is verified or it is not. If the email cannot be 1559 verified, then it SHOULD be rendered the same as all unverified email 1560 regardless of whether it looks like it was signed or not. 1562 Insert the Authentication-Results header field. That header field is 1563 described in [ID-AUTH-RES]. The Authentication-Results header field 1564 SHOULD be inserted before any existing DKIM-Signature or 1565 Authentication-Results header fields in the header field block. 1567 INFORMATIVE ADVICE to MUA filter writers: 1569 Patterns intended to search for Authentication-Results header 1570 fields to visibly mark authenticated mail for end users should 1571 verify that the Authentication-Results header field was added by 1572 the appropriate verifying domain and that the verified identity 1573 matches the sender identity that will be displayed by the MUA. In 1574 particular, MUA patterns should not be influenced by bogus 1575 Authentication-Results header fields added by attackers. 1577 In order to retain the current semantics and visibility of the From 1578 header field, verifying mail agents SHOULD take steps to ensure that 1579 the signing address is prominently visible to the user if it is 1580 different from the From address. If MUA implementations that 1581 highlight the signed address are not available, this MAY be done by 1582 the validating MTA or MDA by rewriting the From address in a manner 1583 which remains compliant with [RFC2822]. Such modifications MUST be 1584 performed after the final verification step since they will break the 1585 signature. If performed, the rewriting SHOULD include the name of 1586 the signer in the address. For example: 1588 From: John Q. User 1590 might be converted to 1592 From: "John Q. User via " 1594 This sort of address inconsistency is expected for mailing lists, but 1595 might be otherwise used to mislead the verifier, for example if a 1596 message supposedly from administration@your-bank.com had a Sender 1597 address of fraud@badguy.com. 1599 Under no circumstances should an unsigned header field be displayed 1600 in any context that might be construed by the end user as having been 1601 signed. Notably, unsigned header fields SHOULD be hidden from the 1602 end user to the extent possible. 1604 7. Compliance 1606 [The issues to be described here have been redirected to the SSP 1607 document. This section will be deleted in the next draft.] 1609 8. IANA Considerations 1611 Use of the _domainkey prefix in DNS records will require registration 1612 by IANA. 1614 To avoid conflicts, tag names for the DKIM-Signature header and key 1615 records should be registered with IANA. 1617 Tag values for the "a=", "c=", and "q=" tags in the DKIM-Signature 1618 header, and the "h=", "k=", "s=", and "t" tags in key records should 1619 be registered with IANA for the same reason. 1621 The DKK and DKP RR types must be registered by IANA. 1623 9. Security Considerations 1625 It has been observed that any mechanism that is introduced which 1626 attempts to stem the flow of spam is subject to intensive attack. 1627 DKIM needs to be carefully scrutinized to identify potential attack 1628 vectors and the vulnerability to each. 1630 9.1 Misuse of Body Length Limits ("l=" Tag) 1632 Body length limits (in the form of the "l=" tag) are subject to 1633 several potential attacks. 1635 9.1.1 Addition of new MIME parts to multipart/* 1637 If the body length limit does not cover a closing MIME multipart 1638 header field (including the trailing "--CRLF" portion), then it is 1639 possible for an attacker to intercept a properly signed multipart 1640 message and add a new body part. Depending on the details of the 1641 MIME type and the implementation of the verifying MTA and the 1642 receiving MUA, this could allow an attacker to change the information 1643 displayed to an end user from an apparently trusted source. 1645 *** Example appropriate here *** 1647 9.1.2 Addition of new HTML content to existing content 1649 Several receiving MUA implementations do not cease display after a 1650 "" tag. In particular, this allows attacks involving 1651 overlaying images on top of existing text. 1653 INFORMATIVE EXAMPLE: Appending the following text to an existing, 1654 properly closed message will in many MUAs result in inappropriate 1655 data being rendered on top of existing, correct data: 1656
1657 1659
1661 9.2 Misappropriated Private Key 1663 If the private key for a user is resident on their computer and is 1664 not protected by an appropriately secure passphrase, it is possible 1665 for malware to send mail as that user and any other user sharing the 1666 same private key. The malware would, however, not be able to 1667 generate signed spoofs of other signers' addresses, which would aid 1668 in identification of the infected user and would limit the 1669 possibilities for certain types of attacks involving socially- 1670 engineered messages. 1672 A larger problem occurs if malware on many users' computers obtains 1673 the private keys for those users and transmits them via a covert 1674 channel to a site where they can be shared. The compromised users 1675 would likely not know of the misappropriation until they receive 1676 "bounce" messages from messages they are supposed to have sent. Many 1677 users might not understand the significance of these bounce messages 1678 and would not take action. 1680 One countermeasure is to use a user-entered passphrase to encrypt the 1681 private key, although users tend to choose weak passphrases and often 1682 reuse them for different purposes, possibly allowing an attack 1683 against DKIM to be extended into other domains. Nevertheless, the 1684 decoded private key might be briefly available to compromise by 1685 malware when it is entered, or might be discovered via keystroke 1686 logging. The added complexity of entering a passphrase each time one 1687 sends a message would also tend to discourage the use of a secure 1688 passphrase. 1690 A somewhat more effective countermeasure is to send messages through 1691 an outgoing MTA that can authenticate the submitter using existing 1692 techniques (e.g., SMTP Authentication), possibly validate the message 1693 itself (e.g., verify that the header is legitimate and that the 1694 content passes a spam content check), and sign the message using a 1695 key appropriate for the submitter address. Such an MTA can also 1696 apply controls on the volume of outgoing mail each user is permitted 1697 to originate in order to further limit the ability of malware to 1698 generate bulk email. 1700 9.3 Key Server Denial-of-Service Attacks 1702 Since the key servers are distributed (potentially separate for each 1703 domain), the number of servers that would need to be attacked to 1704 defeat this mechanism on an Internet-wide basis is very large. 1705 Nevertheless, key servers for individual domains could be attacked, 1706 impeding the verification of messages from that domain. This is not 1707 significantly different from the ability of an attacker to deny 1708 service to the mail exchangers for a given domain, although it 1709 affects outgoing, not incoming, mail. 1711 A variation on this attack is that if a very large amount of mail 1712 were to be sent using spoofed addresses from a given domain, the key 1713 servers for that domain could be overwhelmed with requests. However, 1714 given the low overhead of verification compared with handling of the 1715 email message itself, such an attack would be difficult to mount. 1717 9.4 Attacks Against DNS 1719 Since DNS is a required binding for key services, specific attacks 1720 against DNS must be considered. 1722 While the DNS is currently insecure [RFC3833], it is expected that 1723 the security problems should and will be solved by DNSSEC [RFC4033], 1724 and all users of the DNS will reap the benefit of that work. 1726 Secondly, the types of DNS attacks relevant to DKIM are very costly 1727 and are far less rewarding than DNS attacks on other Internet 1728 applications. 1730 To systematically thwart the intent of DKIM, an attacker must conduct 1731 a very costly and very extensive attack on many parts of the DNS over 1732 an extended period. No one knows for sure how attackers will 1733 respond, however the cost/benefit of conducting prolonged DNS attacks 1734 of this nature is expected to be uneconomical. 1736 Finally, DKIM is only intended as a "sufficient" method of proving 1737 authenticity. It is not intended to provide strong cryptographic 1738 proof about authorship or contents. Other technologies such as 1739 OpenPGP [RFC2440] and S/MIME [RFC2633] address those requirements. 1741 A second security issue related to the DNS revolves around the 1742 increased DNS traffic as a consequence of fetching Selector-based 1743 data as well as fetching signing domain policy. Widespread 1744 deployment of DKIM will result in a significant increase in DNS 1745 queries to the claimed signing domain. In the case of forgeries on a 1746 large scale, DNS servers could see a substantial increase in queries. 1748 9.5 Replay Attacks 1750 In this attack, a spammer sends a message to be spammed to an 1751 accomplice, which results in the message being signed by the 1752 originating MTA. The accomplice resends the message, including the 1753 original signature, to a large number of recipients, possibly by 1754 sending the message to many compromised machines that act as MTAs. 1755 The messages, not having been modified by the accomplice, have valid 1756 signatures. 1758 Partial solutions to this problem involve the use of reputation 1759 services to convey the fact that the specific email address is being 1760 used for spam, and that messages from that signer are likely to be 1761 spam. This requires a real-time detection mechanism in order to 1762 react quickly enough. However, such measures might be prone to 1763 abuse, if for example an attacker resent a large number of messages 1764 received from a victim in order to make them appear to be a spammer. 1766 Large verifiers might be able to detect unusually large volumes of 1767 mails with the same signature in a short time period. Smaller 1768 verifiers can get substantially the same volume information via 1769 existing collaborative systems. 1771 9.6 Limits on Revoking Keys 1773 When a large domain detects undesirable behavior on the part of one 1774 of its users, it might wish to revoke the key used to sign that 1775 user's messages in order to disavow responsibility for messages which 1776 have not yet been verified or which are the subject of a replay 1777 attack. However, the ability of the domain to do so can be limited 1778 if the same key, for scalability reasons, is used to sign messages 1779 for many other users. Mechanisms for explicitly revoking keys on a 1780 per-address basis have been proposed but require further study as to 1781 their utility and the DNS load they represent. 1783 9.7 Intentionally malformed Key Records 1785 It is possible for an attacker to publish key records in DNS which 1786 are intentionally malformed, with the intent of causing a denial-of- 1787 service attack on a non-robust verifier implementation. The attacker 1788 could then cause a verifier to read the malformed key record by 1789 sending a message to one of its users referencing the malformed 1790 record in a (not necessarily valid) signature. Verifiers MUST 1791 thoroughly verify all key records retrieved from DNS and be robust 1792 against intentionally as well as unintentionally malformed key 1793 records. 1795 9.8 Intentionally Malformed DKIM-Signature header fields 1797 Verifiers MUST be prepared to receive messages with malformed DKIM- 1798 Signature header fields, and thoroughly verify the header field 1799 before depending on any of its contents. 1801 10. References 1803 10.1 References -- Normative 1805 [ID-AUTH-RES] 1806 Kucherawy, M., "Message header field for Indicating Sender 1807 Authentication Status", draft-kucherawy-sender-auth-header 1808 field-02 (work in progress), 2005. 1810 [ID-DKIM-RR] 1811 "[*] dk rr", draft-dkk-rr-xx (work in progress), 2005. 1813 [ID-DKIM-SSP] 1814 Allman, E., "DKIM Sender Signing Policy", 1815 draft-allman-dkim-ssp-XX (work in progress), 2005. 1817 [ID-MAIL-ARCH] 1818 Crocker, D., "Internet Mail Architecture", 1819 draft-crocker-email-arch-02 (work in progress), 1820 April 2005. 1822 [OPENSSL] Team, C&D., "", WEB http://www.openssl.org/docs/, 1823 June 2005. 1825 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 1826 Mail: Part I: Message Encryption and Authentication 1827 Procedures", RFC 1421, February 1993. 1829 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1830 Extensions (MIME) Part One: Format of Internet Message 1831 Bodies", RFC 2045, November 1996. 1833 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1834 Part Three: Message header field Extensions for Non-ASCII 1835 Text", RFC 2047, November 1996. 1837 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1838 Requirement Levels", BCP 14, RFC 2119, March 1997. 1840 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1841 April 2001. 1843 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1844 April 2001. 1846 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1847 Standards (PKCS) #1: RSA Cryptography Specifications 1848 Version 2.1", RFC 3447, February 2003. 1850 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 1851 Profile for Internationalized Domain Names (IDN)", 1852 RFC 3491, March 2003. 1854 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1855 Specifications: ABNF", RFC 4234, October 2005. 1857 10.2 References -- Informative 1859 [ID-DKIM-THREATS] 1860 Fenton, J., "Analysis of Threats Motivating DomainKeys 1861 Identified Mail (DKIM)", draft-fenton-dkim-threats-00 1862 (work in progress), September 2005. 1864 [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, 1865 "Security Multiparts for MIME: Multipart/Signed and 1866 Multipart/Encrypted", RFC 1847, October 1995. 1868 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 1869 "OpenPGP Message Format", RFC 2440, November 1998. 1871 [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", 1872 RFC 2633, June 1999. 1874 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 1875 Name System (DNS)", RFC 3833, August 2004. 1877 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1878 Rose, "DNS Security Introduction and Requirements", 1879 RFC 4033, March 2005. 1881 Authors' Addresses 1883 Eric Allman 1884 Sendmail, Inc. 1885 6425 Christie Ave, Suite 400 1886 Emeryville, CA 94608 1887 USA 1889 Phone: +1 510 594 5501 1890 Email: eric+dkim@sendmail.org 1891 URI: 1893 Jon Callas 1894 PGP Corporation 1895 3460 West Bayshore 1896 Palo Alto, CA 94303 1897 USA 1899 Phone: +1 650 319 9016 1900 Email: jon@pgp.com 1902 Mark Delany 1903 Yahoo! Inc 1904 701 First Avenue 1905 Sunnyvale, CA 95087 1906 USA 1908 Phone: +1 408 349 6831 1909 Email: markd+dkim@yahoo-inc.com 1910 URI: 1912 Miles Libbey 1913 Yahoo! Inc 1914 701 First Avenue 1915 Sunnyvale, CA 95087 1916 USA 1918 Email: mlibbeymail-mailsig@yahoo.com 1919 URI: 1921 Jim Fenton 1922 Cisco Systems, Inc. 1923 MS SJ-24/2 1924 170 W. Tasman Drive 1925 San Jose, CA 95134-1706 1926 USA 1928 Phone: +1 408 526 5914 1929 Email: fenton@cisco.com 1930 URI: 1932 Michael Thomas 1933 Cisco Systems, Inc. 1934 MS SJ-9/2 1935 170 W. Tasman Drive 1936 San Jose, CA 95134-1706 1938 Phone: +1 408 525 5386 1939 Email: mat@cisco.com 1941 Appendix A. Usage Examples (INFORMATIVE) 1943 This section taken directly from IIM without serious editing; it 1944 should be updated or deleted before publication. In no case should 1945 these examples be used as guidance when creating an implementation. 1947 A.1 Simple message transfer 1949 The above sections largely describe the process of signing and 1950 verifying a message which goes directly from one user to another. 1951 One special case is where the recipient has requested forwarding of 1952 the email message from the original address to another, through the 1953 use of a Unix .forward file or equivalent. In this case the message 1954 is typically forwarded without modification, except for the addition 1955 of a Received header field to the message and a change in the 1956 Envelope-to address. In this case, the eventual recipient should be 1957 able to verify the original signature since the signed content has 1958 not changed, and attribute the message correctly. 1960 A.2 Outsourced business functions 1962 Outsourced business functions represent a use case that motivates the 1963 need for user-level keying. Examples of outsourced business 1964 functions are legitimate email marketing providers and corporate 1965 benefits providers. In either case, the outsourced function would 1966 like to be able to send messages using the email domain of the client 1967 company. At the same time, the client may be reluctant to register a 1968 key for the provider that grants the ability to send messages for any 1969 address in the domain. 1971 With user-level keying, the outsourcing company can generate a 1972 keypair and the client company can register the public key for a 1973 specific address such as promotions@example.com. This would enable 1974 the provider to send messages using that specific address and have 1975 them verify properly. The client company retains control over the 1976 email address because it retains the ability to revoke the key at any 1977 time. 1979 A.3 PDAs and Similar Devices 1981 PDAs are one example of the use of multiple keys per user. Suppose 1982 that John Doe wanted to be able to send messages using his corporate 1983 email address, jdoe@example.com, and the device did not have the 1984 ability to make a VPN connection to the corporate network. If the 1985 device was equipped with a private key registered for 1986 jdoe@example.com by the administrator of that domain, and appropriate 1987 software to sign messages, John could send IIM messages through the 1988 outgoing network of the PDA service provider. 1990 A.4 Mailing Lists 1992 There is a wide range of behavior in forwarders and mailing lists 1993 (collectively called "forwarders" below), ranging from those which 1994 make no modification to the message itself (other than to add a 1995 Received header field and change the envelope information) to those 1996 which may add header fields, change the Subject header field, add 1997 content to the body (typically at the end), or reformat the body in 1998 some manner. 2000 Forwarders which do not modify the body or signed header fields of a 2001 message with a valid signature MAY re-sign the message as described 2002 below. 2004 Forwarders which make any modification to a message that could result 2005 in its signature becoming invalid SHOULD sign or re-sign using an 2006 appropriate identification (e.g., mailing-list-name@example.net). 2007 Since in so doing the (re-)signer is taking responsibility for the 2008 content of the message, modifying forwarders MAY elect to forward or 2009 re-sign only for messages which were received with valid signatures 2010 or other indications that the messages being signed are not spoofed. 2012 Forwarders which wish to re-sign a message MUST apply a Sender header 2013 field to the message to identify the address being used to sign the 2014 message and MUST remove any preexisting Sender header field as 2015 required by [RFC2822]. The forwarder applies a new IIM-Sig header 2016 field with the signature, public key, and related information of the 2017 forwarder. Previously existing IIM-Sig header fields SHOULD NOT be 2018 removed. 2020 A.5 Affinity Addresses 2022 "Affinity addresses" are email addresses that users employ to have an 2023 email address that is independent of any changes in email service 2024 provider they may choose to make. They are typically associated with 2025 college alumni associations, professional organizations, and 2026 recreational organizations with which they expect to have a long-term 2027 relationship. These domains usually provide forwarding of incoming 2028 email, but (currently) usually depend on the user to send outgoing 2029 messages through their own service provider's MTA. They usually have 2030 an associated Web application which authenticates the user and allows 2031 the forwarding address to be changed. 2033 With DKIM, affinity domains could use the Web application to allow 2034 users to register their own public keys to be used to sign messages 2035 on behalf of their affinity address. This is another application 2036 that takes advantage of user-level keying, and domains used for 2037 affinity addresses would typically have a very large number of user- 2038 level keys. Alternatively, the affinity domain could decide to start 2039 handling outgoing mail, and could operate a mail submission agent 2040 that authenticates users before accepting and signing messages for 2041 them. This is of course dependent on the user's service provider not 2042 blocking the relevant TCP ports used for mail submission. 2044 A.6 Third-party Message Transmission 2046 Third-party message transmission refers to the authorized sending of 2047 mail by an Internet application on behalf of a user. For example, a 2048 website providing news may allow the reader to forward a copy of the 2049 message to a friend; this is typically done using the reader's email 2050 address. This is sometimes referred to as the "Evite problem", named 2051 after the website of the same name that allows a user to send 2052 invitations to friends. 2054 One way this can be handled is to continue to put the reader's email 2055 address in the From field of the message, but put an address owned by 2056 the site into the Sender field, and sign the message on behalf of the 2057 Sender. A verifying MTA SHOULD accept this and rewrite the From 2058 field to indicate the address that was verified, i.e., From: John 2059 Doe via news@news-site.com . 2061 Appendix B. Example of Use (INFORMATIVE) 2063 This section taken directly from DK without serious editing; it 2064 should be updated or deleted before publication. In no case should 2065 these examples be used as guidance when creating an implementation. 2067 This section shows the complete flow of an email from submission to 2068 final delivery, demonstrating how the various components fit 2069 together. 2071 B.1 The user composes an email 2073 From: Joe SixPack 2074 To: Suzie Q 2075 Subject: Is dinner ready? 2076 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 2077 Message-ID: <20030712040037.46341.5F8J@football.example.com> 2079 Hi. 2081 We lost the game. Are you hungry yet? 2083 Joe. 2085 B.2 The email is signed 2087 This email is signed by the example.com outbound email server and now 2088 looks like this: 2090 DKIM-Signature: a=rsa-sha1; s=brisbane; d=example.com; 2091 c=simple; q=dns; i=joe@football.example.com; 2092 h=Received : From : To : Subject : Date : Message-ID; 2093 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ 2094 VoG4ZHRNiYzR; 2095 Received: from dsl-10.2.3.4.football.example.com [10.2.3.4] 2096 by submitserver.example.com with SUBMISSION; 2097 Fri, 11 Jul 2003 21:01:54 -0700 (PDT) 2098 From: Joe SixPack 2099 To: Suzie Q 2100 Subject: Is dinner ready? 2101 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 2102 Message-ID: <20030712040037.46341.5F8J@football.example.com> 2104 Hi. 2106 We lost the game. Are you hungry yet? 2108 Joe. 2110 The signing email server requires access to the private-key 2111 associated with the "brisbane" selector to generate this signature. 2112 Distribution and management of private-keys is outside the scope of 2113 this document. 2115 B.3 The email signature is verified 2117 The signature is normally verified by an inbound SMTP server or 2118 possibly the final delivery agent. However, intervening MTAs can 2119 also perform this verification if they choose to do so. The 2120 verification process uses the domain "example.com" extracted from the 2121 "d=" header field and the selector "brisbane" from the "s=" tag in 2122 the "DKIM-Signature" header field to form the DNS DKIM query for: 2124 brisbane._dkim.example.com 2126 Signature verification starts with the physically last "Received" 2127 header field, the "From" header field, and so forth, in the order 2128 listed in the "h=" tag. Verification follows with a single CRLF 2129 followed by the body (starting with "Hi."). The email is canonically 2130 prepared for verifying with the "simple" method. The result of the 2131 query and subsequent verification of the signature is stored in the 2132 "Authentication-Results" header field line. After successful 2133 verification, the email looks like this: 2135 Authentication-Status: XXX 2136 Received: from mout23.football.example.com (192.168.1.1) 2137 by shopping.example.net with SMTP; 2138 Fri, 11 Jul 2003 21:01:59 -0700 (PDT) 2139 DKIM-Signature: a=rsa-sha1; s=brisbane; d=example.net; 2140 c=simple; q=dns; i=joe@football.example.com; 2141 h=Received : From : To : Subject : Date : Message-ID; 2142 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ 2143 VoG4ZHRNiYzR 2144 Received: from dsl-10.2.3.4.network.example.com [10.2.3.4] 2145 by submitserver.example.com with SUBMISSION; 2146 Fri, 11 Jul 2003 21:01:54 -0700 (PDT) 2147 From: Joe SixPack 2148 To: Suzie Q 2149 Subject: Is dinner ready? 2150 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 2151 Message-ID: <20030712040037.46341.5F8J@football.example.com> 2153 Hi. 2155 We lost the game. Are you hungry yet? 2157 Joe. 2159 Appendix C. Creating a public key (INFORMATIVE) 2161 Drop this section? It seems like this could clarify things for some 2162 people. 2164 The default signature is an RSA signed SHA1 digest of the complete 2165 email. For ease of explanation, the openssl command is used to 2166 describe the mechanism by which keys and signatures are managed. One 2167 way to generate a 768 bit private-key suitable for DKIM, is to use 2168 openssl like this: 2170 $ openssl genrsa ?out rsa.private 768 2172 This results in the file rsa.private containing the key information 2173 similar to this: 2175 -----BEGIN RSA PRIVATE KEY----- 2176 MIIByQIBAAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6lMIgulclWjZwP56LRqdg5 2177 ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7EXzVc+nRLWT1kwTvFNGIo 2178 AUsFUq+J6+OprwIDAQABAmBOX0UaLdWWusYzNol++nNZ0RLAtr1/LKMX3tk1MkLH 2179 +Ug13EzB2RZjjDOWlUOY98yxW9/hX05Uc9V5MPo+q2Lzg8wBtyRLqlORd7pfxYCn 2180 Kapi2RPMcR1CxEJdXOkLCFECMQDTO0fzuShRvL8q0m5sitIHlLA/L+0+r9KaSRM/ 2181 3WQrmUpV+fAC3C31XGjhHv2EuAkCMQDE5U2nP2ZWVlSbxOKBqX724amoL7rrkUew 2182 ti9TEjfaBndGKF2yYF7/+g53ZowRkfcCME/xOJr58VN17pejSl1T8Icj88wGNHCs 2183 FDWGAH4EKNwDSMnfLMG4WMBqd9rzYpkvGQIwLhAHDq2CX4hq2tZAt1zT2yYH7tTb 2184 weiHAQxeHe0RK+x/UuZ2pRhuoSv63mwbMLEZAjAP2vy6Yn+f9SKw2mKuj1zLjEhG 2185 6ppw+nKD50ncnPoP322UMxVNG4Eah0GYJ4DLP0U= 2186 -----END RSA PRIVATE KEY----- 2188 Once a private-key has been generated, the openssl command can be 2189 used to sign an appropriately prepared email, like this: 2191 $ openssl dgst -sign rsa.private -sha1 . 2239 Appendix E. Edit History 2241 E.1 Changes since -00 version 2243 o Changed "c=" tag to separate out header from body 2244 canonicalization. 2246 o Eliminated "nowsp" canonicalization in favor of "relaxed", which 2247 is somewhat less relaxed (but more secure) than "nowsp". 2249 o Moved the (empty) Compliance section to the Sender Signing Policy 2250 document. 2252 o Added several IANA Considerations. 2254 o Fixed a number of grammar and formatting errors. 2256 Intellectual Property Statement 2258 The IETF takes no position regarding the validity or scope of any 2259 Intellectual Property Rights or other rights that might be claimed to 2260 pertain to the implementation or use of the technology described in 2261 this document or the extent to which any license under such rights 2262 might or might not be available; nor does it represent that it has 2263 made any independent effort to identify any such rights. Information 2264 on the procedures with respect to rights in RFC documents can be 2265 found in BCP 78 and BCP 79. 2267 Copies of IPR disclosures made to the IETF Secretariat and any 2268 assurances of licenses to be made available, or the result of an 2269 attempt made to obtain a general license or permission for the use of 2270 such proprietary rights by implementers or users of this 2271 specification can be obtained from the IETF on-line IPR repository at 2272 http://www.ietf.org/ipr. 2274 The IETF invites any interested party to bring to its attention any 2275 copyrights, patents or patent applications, or other proprietary 2276 rights that may cover technology that may be required to implement 2277 this standard. Please address the information to the IETF at 2278 ietf-ipr@ietf.org. 2280 The IETF has been notified of intellectual property rights claimed in 2281 regard to some or all of the specification contained in this 2282 document. For more information consult the online list of claimed 2283 rights. 2285 Disclaimer of Validity 2287 This document and the information contained herein are provided on an 2288 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2289 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2290 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2291 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2292 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2293 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2295 Copyright Statement 2297 Copyright (C) The Internet Society (2005). This document is subject 2298 to the rights, licenses and restrictions contained in BCP 78, and 2299 except as set forth therein, the authors retain all their rights. 2301 Acknowledgment 2303 Funding for the RFC Editor function is currently provided by the 2304 Internet Society.