--- 1/draft-ietf-dkim-rfc4871bis-03.txt 2011-03-28 13:15:58.000000000 +0200 +++ 2/draft-ietf-dkim-rfc4871bis-04.txt 2011-03-28 13:15:58.000000000 +0200 @@ -1,21 +1,21 @@ Network Working Group D. Crocker, Ed. Internet-Draft Brandenburg InternetWorking Obsoletes: 4871 (if approved) T. Hansen, Ed. Intended status: Standards Track AT&T Laboratories -Expires: August 20, 2011 M. Kucherawy, Ed. +Expires: September 29, 2011 M. Kucherawy, Ed. Cloudmark - February 16, 2011 + March 28, 2011 DomainKeys Identified Mail (DKIM) Signatures - draft-ietf-dkim-rfc4871bis-03 + draft-ietf-dkim-rfc4871bis-04 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 @@ -32,137 +32,139 @@ 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 August 20, 2011. + This Internet-Draft will expire on September 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 5 - 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 5 - 1.4. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 - 2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.4. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.5. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 6 - 2.6. Agent or User Identifier (AUID) . . . . . . . . . . . . . 7 - 2.7. Identity Assessor . . . . . . . . . . . . . . . . . . . . 7 - 2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 7 - 2.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 8 - 2.10. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 8 - 2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 8 - 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 9 - 3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 11 - 3.3. Signing and Verification Algorithms . . . . . . . . . . . 12 - 3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 14 - 3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 18 - 3.6. Key Management and Representation . . . . . . . . . . . . 27 - 3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 32 - 3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 34 - 3.9. Relationship between SDID and AUID . . . . . . . . . . . . 34 - 4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 35 - 4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 35 - 4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 37 - 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 38 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 6 + 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 + 1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 6 + 1.4. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 6 + 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 7 + 2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.4. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.5. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 7 + 2.6. Agent or User Identifier (AUID) . . . . . . . . . . . . . 8 + 2.7. Identity Assessor . . . . . . . . . . . . . . . . . . . . 8 + 2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 8 + 2.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 9 + 2.10. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 9 + 2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 9 + 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 10 + 3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 11 + 3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 12 + 3.3. Signing and Verification Algorithms . . . . . . . . . . . 13 + 3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 15 + 3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 19 + 3.6. Key Management and Representation . . . . . . . . . . . . 28 + 3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 33 + 3.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 35 + 3.9. Signing by Parent Domains . . . . . . . . . . . . . . . . 35 + 3.10. Relationship between SDID and AUID . . . . . . . . . . . . 36 + 4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 36 + 4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 37 + 4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 38 + 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 39 5.1. Determine Whether the Email Should Be Signed and by - Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 + Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.2. Select a Private Key and Corresponding Selector - Information . . . . . . . . . . . . . . . . . . . . . . . 38 - - 5.3. Normalize the Message to Prevent Transport Conversions . . 39 - 5.4. Determine the Header Fields to Sign . . . . . . . . . . . 39 - 5.5. Recommended Signature Content . . . . . . . . . . . . . . 41 - 5.6. Compute the Message Hash and Signature . . . . . . . . . . 43 - 5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 43 - 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 44 - 6.1. Extract Signatures from the Message . . . . . . . . . . . 45 - 6.2. Communicate Verification Results . . . . . . . . . . . . . 50 - 6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 51 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 - 7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 52 - 7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 52 - 7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 53 - 7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 53 - 7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 54 - 7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 55 - 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 55 - 7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 55 - 7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 56 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 56 - 8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 56 - 8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 57 - 8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 58 - 8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 58 - 8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 59 - 8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 59 - 8.7. Intentionally Malformed Key Records . . . . . . . . . . . 59 - 8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 60 - 8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 60 - 8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 60 - 8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 60 - 8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 60 - 8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 61 - 8.14. Attacks Involving Addition of Header Fields . . . . . . . 61 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 62 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 63 - Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 64 - A.1. The User Composes an Email . . . . . . . . . . . . . . . . 64 - A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 64 - A.3. The Email Signature is Verified . . . . . . . . . . . . . 65 - Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 66 - B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 67 - B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 69 - Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 71 - Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 72 - Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 72 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73 + Information . . . . . . . . . . . . . . . . . . . . . . . 40 + 5.3. Normalize the Message to Prevent Transport Conversions . . 40 + 5.4. Determine the Header Fields to Sign . . . . . . . . . . . 41 + 5.5. Recommended Signature Content . . . . . . . . . . . . . . 43 + 5.6. Compute the Message Hash and Signature . . . . . . . . . . 44 + 5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 45 + 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 45 + 6.1. Extract Signatures from the Message . . . . . . . . . . . 46 + 6.2. Communicate Verification Results . . . . . . . . . . . . . 51 + 6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 52 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 + 7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 53 + 7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 54 + 7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 54 + 7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 54 + 7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 55 + 7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 56 + 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 56 + 7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 56 + 7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 57 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 57 + 8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 57 + 8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 58 + 8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 59 + 8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 59 + 8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 60 + 8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 60 + 8.7. Intentionally Malformed Key Records . . . . . . . . . . . 60 + 8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 61 + 8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 61 + 8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 61 + 8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 61 + 8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 61 + 8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 62 + 8.14. Attacks Involving Addition of Header Fields . . . . . . . 62 + 8.15. Malformed Inputs . . . . . . . . . . . . . . . . . . . . . 63 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 64 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 65 + Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 66 + A.1. The User Composes an Email . . . . . . . . . . . . . . . . 66 + A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 66 + A.3. The Email Signature is Verified . . . . . . . . . . . . . 67 + Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 68 + B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 69 + B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 71 + Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 73 + Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 74 + Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 74 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 1. 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]. 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 querying the signer's domain directly to - retrieve the appropriate public key. Message transit from author to - recipient is through relays that typically make no substantive change - to the message content and thus preserve the DKIM signature. A - message can contain multiple signatures, from the same or different - organizations involved with the message. + 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 + querying the signer's domain directly to retrieve the appropriate + public key. Message transit from author to recipient is through + relays that typically make no substantive change to the message + content and thus preserve the DKIM signature. A message can contain + multiple signatures, from the same or different organizations + involved with the message. The approach taken by DKIM differs from previous approaches to message signing (e.g., Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC1847], OpenPGP [RFC4880]) in that: o the message signature is written as a message header field so that neither human recipients nor existing MUA (Mail User Agent) software is confused by signature-related content appearing in the message body; @@ -264,23 +267,23 @@ Elements in the mail system that verify signatures are referred to as verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs. In most cases it is expected that verifiers will be close to an end user (reader) of the message or some consuming agent such as a mailing list exploder. 2.3. Identity A person, role, or organization. In the context of DKIM, examples - include author, author's organization, an ISP along the handling - path, an independent trust assessment service, and a mailing list - operator. + include the author, the author's organization, an ISP along the + handling path, an independent trust assessment service, and a mailing + list operator. 2.4. Identifier A label that refers to an identity. 2.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 @@ -1440,84 +1443,93 @@ beginning with a "." to avoid confusion with the SMTP end-of-message marker, as specified in [RFC5321]). With the exception of the canonicalization procedure described in Section 3.4, the DKIM signing process treats the body of messages as simply a string of octets. DKIM messages MAY be either in plain-text or in MIME format; no special treatment is afforded to MIME content. Message attachments in MIME format MUST be included in the content that is signed. - More formally, the ABNF of the algorithm for the signature is as - follows: - body-hash = bh-hash-alg (canon-body, l-param) - data-hash = a-hash-alg (h-headers, D-SIG, content-hash) + More formally, pseudo-code for the signature algorithm is: + body-hash = hash-alg (canon-body, l-param) + data-hash = hash-alg (h-headers, D-SIG, content-hash) signature = sig-alg (d-domain, selector, data-hash) where: - body-hash: is the output of a function to hash the Body. + body-hash: is the output from hashing the body, using hash-alg. - bh-hash-alg: is the hashing algorithm specified in the "bh" + hash-alg: is the hashing algorithm specified in the "a" parameter. - canon-body: is a canonicalized representation of the body. + canon-body: is a canonicalized representation of the body, + produced by using the body algorithm specified in the "c" + parameter, as defined in Section 3.4 and excluding the + DKIM-Signature field. - l-param: is the value of the l= length parameter. + l-param: is the length-of-body value of the "l" parameter. - data-hash: is the output from hashing the header, the - DOSETA-Signature header, and the Content hash. + data-hash: is the output from using the hash-alg algorithm, to + hash the header including the DKIM-Signature header, and the + body hash. - a-hash-alg: is the hash algorithm specified by the "a=" tag, h-headers: is the list of headers to be signed, as specified in - the h= parameter. - - D-SIG: is the canonicalized DOSETA-Signature field sans the - signature value itself. + the "h" parameter. - canon-body: is the canonicalized Body as defined in Section 3.4 - (excluding the DKIM-Signature field). + D-SIG: is the canonicalized DKIM-Signature field without the + signature value portion of the parameter, itself; that is, an + empty parameter value. signature: is the signature value produced by the signing algorithm. - sig-alg: is the signature algorithm specified by the "a=" tag, + sig-alg: is the signature algorithm specified by the "a" + parameter. - d-domain: is the domain name specified in the d= parameter. + d-domain: is the domain name specified in the "d" parameter. - selector: is the value of the s= selector parameter + selector: is the selector value specified in the "s" parameter. NOTE: Many digital signature APIs provide both hashing and application of the RSA private key using a single "sign()" primitive. When using such an API, the last two steps in the algorithm would probably be combined into a single call that would perform both the "a-hash-alg" and the "sig-alg". -3.8. Signing by Parent Domains +3.8. Input Requirements + + DKIM's design is predicated on valid input. Therefore, signers and + verifiers SHOULD take reasonable steps to ensure that the messages + they are processing are valid according to [RFC5322], [RFC2045], and + any other relevant message format standards. See Section 8.15 for + additional discussion and references. + +3.9. Signing by Parent Domains In some circumstances, it is desirable for a domain to apply a signature on behalf of any of its subdomains without the need to maintain separate selectors (key records) in each subdomain. By default, private keys corresponding to key records can be used to sign messages for any subdomain of the domain in which they reside; for example, a key record for the domain example.com can be used to verify messages where the AUID ("i=" tag of the signature) is sub.example.com, or even sub1.sub2.example.com. In order to limit the capability of such keys when this is not intended, the "s" flag MAY be set in the "t=" tag of the key record, to constrain the validity of the domain of the AUID. If the referenced key record contains the "s" flag as part of the "t=" tag, the domain of the AUID ("i=" flag) MUST be the same as that of the SDID (d=) domain. If this flag is absent, the domain of the AUID MUST be the same as, or a subdomain of, the SDID. -3.9. Relationship between SDID and AUID +3.10. Relationship between SDID and AUID DKIM's primary task is to communicate from the Signer to a recipient- side Identity Assessor a single Signing Domain Identifier (SDID) that refers to a responsible identity. DKIM MAY optionally provide a single responsible Agent or User Identifier (AUID). Hence, DKIM's mandatory output to a receive-side Identity Assessor is a single domain name. Within the scope of its use as DKIM output, the name has only basic domain name semantics; any possible owner- specific semantics are outside the scope of DKIM. That is, within @@ -1722,21 +1733,21 @@ to modification during transit, notably conversion to 7-bit form. Such conversions will break DKIM signatures. In order to minimize the chances of such breakage, signers SHOULD convert the message to a suitable MIME content transfer encoding such as quoted-printable or base64 as described in [RFC2045] before signing. Such conversion is outside the scope of DKIM; the actual message SHOULD be converted to 7-bit MIME by an MUA or MSA prior to presentation to the DKIM algorithm. Similarly, a message that is not compliant with RFC5322, RFC2045 and - RFC2047, can be subject to attempts by intermediaries to correct or + RFC2047 can be subject to attempts by intermediaries to correct or interpret such content. See Section 8 of [RFC4409] for examples of changes that are commonly made. Such "corrections" may break DKIM signatures or have other undesirable effects. Therefore, a verifier SHOULD NOT validate a message that is not compliant with those specifications. If the message is submitted to the signer with any local encoding that will be modified before transmission, that modification to canonical [RFC5322] form MUST be done before signing. In particular, bare CR or LF characters (used by some systems as a local line @@ -2123,24 +2133,25 @@ The public key for a signature is needed to complete the verification process. The process of retrieving the public key depends on the query type as defined by the "q=" tag in the DKIM-Signature header field. Obviously, a public key need only be retrieved if the process of extracting the signature information is completely successful. Details of key management and representation are described in Section 3.6. The verifier MUST validate the key record and MUST ignore any public key records that are malformed. - NOTE: The use of wildcard TXT records in the DNS will produce a - response to a DKIM query that is unlikely to be valid DKIM key - record. This problem applies to many other types of queries, and - client software that processes DNS responses needs to take this + NOTE: The use of a wildcard TXT record that covers a queried DKIM + domain name will produce a response to a DKIM query that is + unlikely to be valid DKIM key record. This problem is not + specific to DKIM and applies to many other types of queries. + Client software that processes DNS responses needs to take this problem into account. When validating a message, a verifier MUST perform the following steps in a manner that is semantically the same as performing them in the order indicated -- in some cases the implementation may parallelize or reorder these steps, as long as the semantics remain unchanged: 1. Retrieve the public key as described in Section 3.6 using the algorithm in the "q=" tag, the domain from the "d=" tag, and the @@ -2736,21 +2747,21 @@ by refusing to verify signatures that reference selectors with public keys having unreasonable exponents. In general, an attacker might try to overwhelm a verifier by flooding it with messages requiring verification. This is similar to other MTA denial-of-service attacks and should be dealt with in a similar fashion. 8.13. Inappropriate Signing by Parent Domains - The trust relationship described in Section 3.8 could conceivably be + The trust relationship described in Section 3.9 could conceivably be used by a parent domain to sign messages with identities in a subdomain not administratively related to the parent. For example, the ".com" registry could create messages with signatures using an "i=" value in the example.com domain. There is no general solution to this problem, since the administrative cut could occur anywhere in the domain name. For example, in the domain "example.podunk.ca.us" there are three administrative cuts (podunk.ca.us, ca.us, and us), any of which could create messages with an identity in the full domain. @@ -2789,25 +2800,64 @@ 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. 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 + 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. +8.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:, + + 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 + 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. + + Because of this, DKIM implementers are strongly advised to reject or + treat as suspicious any message that has multiple copies of header + fields that are disallowed by section 3.6 of [MAIL], particularly + those that are typically displayed to end users (From:, To:, Cc:, + Subject:). 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 + from the IANA "Permanent Header Field Registry" and the reference + documents it identifies. + 9. References 9.1. Normative References [FIPS-180-2-2002] U.S. Department of Commerce, "Secure Hash Standard", FIPS PUB 180-2, August 2002. [ITU-X660-1997] "Information Technology - ASN.1 encoding rules: