--- 1/draft-ietf-dkim-rfc4871bis-07.txt 2011-04-28 09:15:49.000000000 +0200 +++ 2/draft-ietf-dkim-rfc4871bis-08.txt 2011-04-28 09:15:49.000000000 +0200 @@ -1,21 +1,21 @@ Network Working Group D. Crocker, Ed. Internet-Draft Brandenburg InternetWorking Obsoletes: 4871, 5672 T. Hansen, Ed. (if approved) AT&T Laboratories Intended status: Standards Track M. Kucherawy, Ed. -Expires: October 26, 2011 Cloudmark - April 24, 2011 +Expires: October 29, 2011 Cloudmark + April 27, 2011 DomainKeys Identified Mail (DKIM) Signatures - draft-ietf-dkim-rfc4871bis-07 + draft-ietf-dkim-rfc4871bis-08 Abstract DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay or one of their agents. DKIM separates the question of the identity of the signer of the message from the purported author of the message. Assertion of responsibility is validated through a @@ -34,21 +34,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 26, 2011. + This Internet-Draft will expire on October 29, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -79,39 +79,39 @@ 3.10. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 9 3.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 10 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 13 4.3. Signing and Verification Algorithms . . . . . . . . . . . 14 4.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15 4.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 20 4.6. Key Management and Representation . . . . . . . . . . . . 29 4.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33 - 4.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 36 + 4.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 35 4.9. Signing by Parent Domains . . . . . . . . . . . . . . . . 36 4.10. Relationship between SDID and AUID . . . . . . . . . . . . 36 5. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 37 5.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 37 5.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 38 6. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 39 6.1. Determine Whether the Email Should Be Signed and by - Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 + Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.2. Select a Private Key and Corresponding Selector Information . . . . . . . . . . . . . . . . . . . . . . . 40 - 6.3. Normalize the Message to Prevent Transport Conversions . . 41 + 6.3. Normalize the Message to Prevent Transport Conversions . . 40 6.4. Determine the Header Fields to Sign . . . . . . . . . . . 41 6.5. Recommended Signature Content . . . . . . . . . . . . . . 43 6.6. Compute the Message Hash and Signature . . . . . . . . . . 45 6.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 45 7. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 46 7.1. Extract Signatures from the Message . . . . . . . . . . . 46 - 7.2. Communicate Verification Results . . . . . . . . . . . . . 52 + 7.2. Communicate Verification Results . . . . . . . . . . . . . 51 7.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 52 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 8.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 53 8.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 54 8.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 54 8.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 55 8.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 56 8.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 56 8.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 56 8.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 57 @@ -144,21 +144,21 @@ B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 71 Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 73 C.1. Compatibility with DomainKeys Key Records . . . . . . . . 74 Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 74 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76 1. Notes to Editor and Reviewers This version of the memo contains notations such as "{DKIM 2}". - These correspond to DKIM working group issue tracker items. they + These correspond to DKIM working group issue tracker items. They should be deleted prior to publication. 2. Introduction DomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name [RFC1034] with the message [RFC5322], which they are authorized to use. This can be an author's organization, an operational relay or one of their agents. Assertion of responsibility is validated through a cryptographic signature and @@ -288,25 +288,22 @@ handling path, an independent trust assessment service, and a mailing list operator. 3.4. Identifier A label that refers to an identity. 3.5. Signing Domain Identifier (SDID) A single domain name that is the mandatory payload output of DKIM and - that refers to the identity claiming responsibility for introduction - of a message into the mail stream. For DKIM processing, the name has - only basic domain name semantics; any possible owner-specific - semantics are outside the scope of DKIM. It is specified in - Section 4.5. + that refers to the identity claiming some responsibility for the + message by signing it. It is specified in Section 4.5. 3.6. Agent or User Identifier (AUID) A single identifier that refers to the agent or user on behalf of whom the Signing Domain Identifier (SDID) has taken responsibility. The AUID comprises a domain name and an optional . The domain name is the same as that used for the SDID or is a sub-domain of it. For DKIM processing, the domain name portion of the AUID has only basic domain name semantics; any possible owner-specific semantics are outside the scope of DKIM. It is specified in @@ -568,25 +565,24 @@ empty value explicitly designates the empty string as the value. 4.3. Signing and Verification Algorithms DKIM supports multiple digital signature algorithms. Two algorithms are defined by this specification at this time: rsa-sha1 and rsa- sha256. Signers MUST implement and SHOULD sign using rsa-sha256. Verifiers MUST implement rsa-sha256. INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged, some - senders of low-security messages (such as routine newsletters) may - prefer to use rsa-sha1 because of reduced CPU requirements to - compute a SHA1 hash. MTAs with compliant verifierst that do not - implement rsa-sha1 will treat such messages as unsigned. {DKIM 13} - In general, rsa-sha256 should always be used whenever possible. + senders might prefer to use rsa-sha1 when balancing security + strength against performance, complexity, or other needs. + However, compliant verifiers might not implement rsa-sha1; they + will treat such messages as unsigned. {DKIM 13} 4.3.1. The rsa-sha1 Signing Algorithm The rsa-sha1 Signing Algorithm computes a message hash as described in Section 4.7 below using SHA-1 [FIPS-180-2-2002] as the hash-alg. That hash is then signed by the signer using the RSA algorithm (defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the signer's private key. The hash MUST NOT be truncated or converted into any form other than the native binary form before being signed. The signing algorithm SHOULD use a public exponent of 65537. @@ -952,22 +949,22 @@ d= The SDID claiming responsibility for an introduction of a message into the mail stream (plain-text; REQUIRED). Hence, the SDID value is used to form the query for the public key. The SDID MUST correspond to a valid DNS name under which the DKIM key record is published. The conventions and semantics used by a signer to create and use a specific SDID are outside the scope of the DKIM Signing specification, as is any use of those conventions and semantics. When presented with a signature that does not meet these requirements, verifiers MUST consider the signature invalid. - Internationalized domain names MUST be encoded as described in - Section 2.3 of [RFC5890] to "A-Labels". {DKIM 4}. + Internationalized domain names MUST be encoded as A-Labels, as + described in Section 2.3 of [RFC5890]. {DKIM 4}. ABNF: sig-d-tag = %x64 [FWS] "=" [FWS] domain-name domain-name = sub-domain 1*("." sub-domain) ; from RFC5321 Domain, excluding address-literal h= Signed header fields (plain-text, but see description; REQUIRED). A colon-separated list of header field names that identify the header fields presented to the signing algorithm. The field MUST @@ -1004,22 +1001,22 @@ i= The Agent or User Identifier (AUID) on behalf of which the SDID is taking responsibility (dkim-quoted-printable; OPTIONAL, default is an empty Local-part followed by an "@" followed by the domain from the "d=" tag). The syntax is a standard email address where the Local-part MAY be omitted. The domain part of the address MUST be the same as, or a subdomain of, the value of the "d=" tag. - Internationalized domain names MUST be converted as described in - Section 2.3 of [RFC5890] to "A-Labels" {DKIM 4}. + Internationalized domain names MUST be encoded as A-Labels, as + described in Section 2.3 of [RFC5890]. {DKIM 4}. ABNF: sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" domain-name The AUID is specified as having the same syntax as an email address, but is not required to have the same semantics. Notably, the domain name is not required to be registered in the DNS -- so it might not resolve in a query -- and the Local-part MAY be drawn @@ -1113,23 +1111,27 @@ "txt", which MUST be included. Verifiers and signers MUST support "dns/txt". ABNF: sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method *([FWS] ":" [FWS] sig-q-tag-method) sig-q-tag-method = "dns/txt" / x-sig-q-tag-type ["/" x-sig-q-tag-args] x-sig-q-tag-type = hyphenated-word ; for future extension x-sig-q-tag-args = qp-hdr-value + s= The selector subdividing the namespace for the "d=" (domain) tag (plain-text; REQUIRED). + Internationalized selector names MUST be encoded as A-Labels, as + described in Section 2.3 of [RFC5890]. {DKIM 4}. + ABNF: sig-s-tag = %x73 [FWS] "=" [FWS] selector t= Signature Timestamp (plain-text unsigned decimal integer; RECOMMENDED, default is an unknown creation time). The time that this signature was created. The format is the number of seconds since 00:00:00 on January 1, 1970 in the UTC time zone. The value is expressed as an unsigned integer in decimal ASCII. This value is not constrained to fit into a 31- or 32-bit integer. Implementations SHOULD be prepared to handle values up to at least @@ -1845,78 +1846,82 @@ INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this specification, all end-user visible header fields should be signed to avoid possible "indirect spamming". For example, if the Subject header field is not signed, a spammer can resend a previously signed mail, replacing the legitimate subject with a one-line spam. 6.5. Recommended Signature Content - In order to maximize compatibility with a variety of verifiers, it is - recommended that signers follow the practices outlined in this - section when signing a message. However, these are generic - recommendations applying to the general case; specific senders may - wish to modify these guidelines as required by their unique - situations. Verifiers MUST be capable of verifying signatures even - if one or more of the recommended header fields is not signed (with - the exception of From, which must always be signed) or if one or more - of the dis-recommended header fields is signed. Note that verifiers - do have the option of ignoring signatures that do not cover a - sufficient portion of the header or body, just as they may ignore - signatures from an identity they do not trust. - - The following header fields SHOULD be included in the signature, if - they are present in the message being signed: + {DKIM 20} - o From (REQUIRED in all signatures) + The purpose of the DKIM cryptographic algorithm is to affix an + identifier to the message in a way that is both robust against normal + transit-related changes and resistant to kinds of replay attacks. An + essential aspect of satisfying these requirements is choosing what + header fields to include in the hash and what fields to exclude. - o Sender, Reply-To + The basic rule for choosing fields to include is to select those + fields that constitute the "core" of the message content. Hence, any + replay attack will have to include these in order to have the + signature succeed; but with these included, the core of the message + is valid, even if sent on to new recipients. - o Subject + Common examples of fields with addresses and fields with textual + content related to the body are: - o Date, Message-ID + o From (REQUIRED; see Section 6.4) - o To, Cc + o Reply-To - o MIME-Version + o Subject - o Content-Type, Content-Transfer-Encoding, Content-ID, Content- - Description + o Date - o Resent-Date, Resent-From, Resent-Sender, Resent-To, Resent-Cc, - Resent-Message-ID + o To, Cc + o Resent-Date, Resent-From, Resent-To, Resent-Cc o In-Reply-To, References o List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive - The following header fields SHOULD NOT be included in the signature: + If the "l=" signature tag is in use (see Section 4.5), the Content- + Type field is also a candidate for being included as it could be + replaced in a way that causes completely different content to be + rendered to the receiving user. + + Another class of fields that may be of interest are those that convey + security-related information about the message, such as + Authentication-Results [RFC5451]. + + The basic rule for choosing field to exclude is to select those + fields for which there are multiple fields with the same name, and + fields that are modified in transit. Examples of these are: o Return-Path o Received o Comments, Keywords - o Bcc, Resent-Bcc - - o DKIM-Signature + Note that the DKIM-Signature field is also excluded from the header + hash, because its handling is specified separately. - Optional header fields (those not mentioned above) normally SHOULD - NOT be included in the signature, because of the potential for - additional header fields of the same name to be legitimately added or - reordered prior to verification. There are likely to be legitimate - exceptions to this rule, because of the wide variety of application- - specific header fields that may be applied to a message, some of - which are unlikely to be duplicated, modified, or reordered. + Typically, it is better to exclude other, optional fields because of + the potential that additional fields of the same name will be + legitimately added or re-ordered prior to verification. There are + likely to be legitimate exceptions to this rule, because of the wide + variety of application-specific header fields that might be applied + to a message, some of which are unlikely to be duplicated, modified, + or reordered. Signers SHOULD choose canonicalization algorithms based on the types of messages they process and their aversion to risk. For example, e-commerce sites sending primarily purchase receipts, which are not expected to be processed by mailing lists or other software likely to modify messages, will generally prefer "simple" canonicalization. Sites sending primarily person-to-person email will likely prefer to be more resilient to modification during transport by using "relaxed" canonicalization. @@ -2767,79 +2771,76 @@ Many email implementations do not enforce [RFC5322] with strictness. As discussed in Section 6.3 DKIM processing is predicated on a valid mail message as its input. However, DKIM implementers should be aware of the potential effect of having loose enforcement by email components interacting with DKIM modules. For example, a message with multiple From: header fields violates Section 3.6 of [RFC5322]. With the intent of providing a better user experience, many agents tolerate these violations and deliver the message anyway. An MUA then might elect to render to the user the - value of the last, or "top", From: field. This may also be done - simply out of the expectation that there is only one, where a "find - first" algorithm would have the same result. Such code in an MUA can - be exploited to fool the user if it is also known that the other - From: field is the one checked by arriving message filters. Such is - the case with DKIM; although the From: field must be signed, a - malformed message bearing more than one From: field might only have + value of the first {DKIM 16}, or "top", From: field. This may also + be done simply out of the expectation that there is only one, where a + "find first" algorithm would have the same result. Such code in an + MUA can be exploited to fool the user if it is also known that the + other From: field is the one checked by arriving message filters. + Such is the case with DKIM; although the From: field must be signed, + a malformed message bearing more than one From: field might only have the first ("bottom") one signed, in an attempt to show the message with some "DKIM passed" annotation while also rendering the From: field that was not authenticated. (This can also be taken as a demonstration that DKIM is not designed to support author validation.) - To resist this specific attack the signed header field list can - include an additional reference for each field that was present at - signing. For example, a proper message with one From: field could be - signed using "h=From:From:..." Due to the way header fields are - canonicalized for input to the hash function, the extra field - references will prevent instances of the cited fields from being - added after signing, as doing so would render the signature invalid. + Note that the technique for using "h=...:from:from:...", described in + Section 9.15 below, is of no effect in the case of an attacker that + is also the signer. {DKIM 16} The From: field is used above to illustrate this issue, but it is only one of several fields that Section 3.6 of [RFC5322] constrains - in this way. In reality any agent that forgives malformations, or is - careless about identifying which parts of a message were - authenticated, is open to exploitation. + in this way. In reality any agent that forgives such malformations + {DKIM 16}, or is careless about identifying which parts of a message + were authenticated, is open to exploitation. 9.15. Malformed Inputs DKIM allows additional header fields to be added to a signed message without breaking the signature. This tolerance can be abused, for - example in a replay attack. The attack is accomplished by creating - additional instances of header fields to an already signed message, - without breaking the signature. These then might be displayed to the - end user or are used as filtering input. Salient fields could - include From: and Subject:, + example in a replay attack or a man-in-the-middle attack {DKIM 16}. + The attack is accomplished by creating additional instances of header + fields to an already signed message, without breaking the signature. + These then might be displayed to the end user or are used as + filtering input. Salient fields could include From: and Subject:, The resulting message violates section 3.6 of [RFC5322]. The way such input will be handled and displayed by an MUA is unpredictable, - but in some cases it might display the newly added header fields + but it will commonly {DKIM 16} display the newly added header fields rather than those that are part of the originally signed message alongside some "valid DKIM signature" annotation. This might allow an attacker to replay a previously sent, signed message with a different Subject:, From: or To: field. However, [RFC5322] also tolerates obsolete message syntax, which does allow things like multiple From: fields on messages. The implementation of DKIM thus potentially creates a more stringent layer of expectation regarding the meaning of an identity, while that additional meaning is either obscured from or incorrectly presented to an end user in this context. Implementers need to consider this possibility when designing their input handling functions. Outright rejection of messages that - violate Section 3.6 of [RFC5322] will interfere with delivery of - legacy formats. Instead, given such input, a signing module could - return an error rather than generate a signature; a verifying module - might return a syntax error code or arrange not to return a positive - result even if the signature technically validates. + violate the relevant standards such as [RFC5322], [RFC2045], etc. + will interfere with delivery of {DKIM 16} legacy formats. Instead, + given such input, a signing module could return an error rather than + generate a signature; a verifying module might return a syntax error + code or arrange not to return a positive result even if the signature + technically validates. Senders concerned that their messages might be particularly vulnerable to this sort of attack and who do not wish to rely on receiver filtering of invalid messages can ensure that adding additional header fields will break the DKIM signature by including two copies of the header fields about which they are concerned in the signature (e.g. "h= ... from:from:to:to:subject:subject ..."). See Sections 3.5 and 5.4 for further discussion of this mechanism. Specific validity rules for all known header fields can be gleaned @@ -3293,20 +3293,21 @@ similar to this: -----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI MmPSPDdQPNUYckcQ2QIDAQAB -----END PUBLIC KEY----- This public-key data (without the BEGIN and END tags) is placed in the DNS: + $ORIGIN _domainkey.example.org. {DKIM 10} brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ" "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt" "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v" "/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi" "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB") C.1. Compatibility with DomainKeys Key Records DKIM key records were designed to be backwards-compatible in many cases with key records used by DomainKeys [RFC4870] (sometimes