content to completely replace the original content in the end recipient's eyes and to defeat duplicate message detection algorithms. An example of such an attack includes altering the MIME structure, exploiting lax HTML parsing in the MUA, and defeating duplicate message detection algorithms. To avoid this attack, Signers should be extremely wary of using this tag, and Assessors might wish to ignore signatures that use the tag.
service attack (see [RFC4732]). However, given the low overhead of verification compared with handling of the email message itself, such an attack would be difficult to mount. RFC3833], these security problems are the motivation behind DNS Security (DNSSEC) [RFC4033], and all users of the DNS will reap the benefit of that work. DKIM is only intended as a "sufficient" method of proving authenticity. It is not intended to provide strong cryptographic proof about authorship or contents. Other technologies such as OpenPGP [RFC4880] and S/MIME [RFC5751] address those requirements. A second security issue related to the DNS revolves around the increased DNS traffic as a consequence of fetching selector-based data as well as fetching signing domain policy. Widespread deployment of DKIM will result in a significant increase in DNS queries to the claimed signing domain. In the case of forgeries on a large scale, DNS servers could see a substantial increase in queries. A specific DNS security issue that should be considered by DKIM Verifiers is the name chaining attack described in Section 2.3 of [RFC3833]. A DKIM Verifier, while verifying a DKIM-Signature header field, could be prompted to retrieve a key record of an attacker's choosing. This threat can be minimized by ensuring that name servers, including recursive name servers, used by the Verifier enforce strict checking of "glue" and other additional information in DNS responses and are therefore not vulnerable to this attack.
react quickly enough. However, such measures might be prone to abuse, if, for example, an attacker re-sent a large number of messages received from a victim in order to make the victim appear to be a spammer. Large Verifiers might be able to detect unusually large volumes of mails with the same signature in a short time period. Smaller Verifiers can get substantially the same volume of information via existing collaborative systems.
BONEH03]. Implementations should consider obfuscating the timing to prevent such attacks. Section 3.10 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. INFORMATIVE NOTE: This is considered an acceptable risk for the same reason that it is acceptable for domain delegation. For example, in the case above, any of the domains could potentially simply delegate "example.podunk.ca.us" to a server of their choice
and completely replace all DNS-served information. Note that a Verifier MAY ignore signatures that come from an unlikely domain such as ".com", as discussed in Section 6.1.1. RFC5322], such as by having multiple instances of a field that is only permitted once), that become malformed in transit, or that contain header or body content that is not true or valid. Use of DKIM on such messages might constitute an attack against a receiver, especially where additional credence is given to a signed message without adequate evaluation of the Signer. These can represent serious attacks, but they have nothing to do with DKIM; they are attacks on the recipient or on the wrongly identified author. Moreover, an agent would be incorrect to infer that all instances of a header field are signed just because one is. A genuine signature from the domain under attack can be obtained by legitimate means, but extra header fields can then be added, either by interception or by replay. In this scenario, DKIM can aid in detecting addition of specific fields in transit. This is done by having the Signer list the field name(s) in the "h=" tag an extra time (e.g., "h=from:from:..." for a message with one From field), so that addition of an instance of that field downstream will render the signature unable to be verified. (See Section 3.5 for details.) This, in essence, is an explicit indication that the Signer repudiates responsibility for such a malformed message. DKIM signs and validates the data it is told to and works correctly. So in this case, DKIM has done its job of delivering a validated domain (the "d=" value) and, given the semantics of a DKIM signature, essentially the Signer has taken some responsibility for a problematic message. It is up to the Identity Assessor or some other
subsequent agent to act on such messages as needed, such as degrading the trust of the message (or, indeed, of the Signer), warning the recipient, or even refusing delivery. All components of the mail system that perform loose enforcement of other mail standards will need to revisit that posture when incorporating DKIM, especially when considering matters of potential attacks such as those described. [FIPS-180-3-2008] U.S. Department of Commerce, "Secure Hash Standard", FIPS PUB 180-3, October 2008. [ITU-X660-1997] "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", 1997. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010. [BONEH03] "Remote Timing Attacks are Practical", Proceedings 12th USENIX Security Symposium, 2003. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004. [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004. [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006. [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006. [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- Service Considerations", RFC 4732, December 2006.
[RFC4870] Delany, M., "Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, May 2007. [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009. [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Identified Mail (DKIM) Service Overview", RFC 5585, July 2009. [RFC5672] Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update", RFC 5672, August 2009. [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, "DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations", RFC 5863, May 2010. [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and Mailing Lists", RFC 6377, September 2011.
Appendix C. From: Joe SixPack <firstname.lastname@example.org> To: Suzie Q <email@example.com> Subject: Is dinner ready? Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Message-ID: <20030712040037.46341.5F8J@football.example.com> Hi. We lost the game. Are you hungry yet? Joe. Figure 1: The User Composes an Email
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com; c=simple/simple; q=dns/txt; firstname.lastname@example.org; h=Received : From : To : Subject : Date : Message-ID; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4=; Received: from client1.football.example.com [192.0.2.1] by submitserver.example.com with SUBMISSION; Fri, 11 Jul 2003 21:01:54 -0700 (PDT) From: Joe SixPack <email@example.com> To: Suzie Q <firstname.lastname@example.org> Subject: Is dinner ready? Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Message-ID: <20030712040037.46341.5F8J@football.example.com> Hi. We lost the game. Are you hungry yet? Joe. Figure 2: The Email is Signed The signing email server requires access to the private key associated with the "brisbane" selector to generate this signature.
X-Authentication-Results: shopping.example.net email@example.com; dkim=pass Received: from mout23.football.example.com (192.168.1.1) by shopping.example.net with SMTP; Fri, 11 Jul 2003 21:01:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com; c=simple/simple; q=dns/txt; firstname.lastname@example.org; h=Received : From : To : Subject : Date : Message-ID; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4=; Received: from client1.football.example.com [192.0.2.1] by submitserver.example.com with SUBMISSION; Fri, 11 Jul 2003 21:01:54 -0700 (PDT) From: Joe SixPack <email@example.com> To: Suzie Q <firstname.lastname@example.org> Subject: Is dinner ready? Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Message-ID: <20030712040037.46341.5F8J@football.example.com> Hi. We lost the game. Are you hungry yet? Joe. Figure 3: Successful Verification
If the client organization retains responsibility for all of the DNS administration, the outsourcing company can generate a key pair, supplying the public key to the client company, which then registers it in the query service using a unique selector. The client company retains control over the use of the delegated key because it retains the ability to revoke the key at any time. If the client wants the delegated group to do the DNS administration, it can have the domain name that is specified with the selector point to the provider's DNS server. The provider then creates and maintains all of the DKIM signature information for that selector. Hence, the client cannot provide constraints on the local-part of addresses that get signed, but it can revoke the provider's signing rights by removing the DNS delegation record.
changed. However, these services usually depend on users sending outgoing messages through their own service provider's MTAs. Hence, mail that is signed with the domain of the affinity address is not signed by an entity that is administered by the organization owning that domain. With DKIM, affinity domains could use the Web application to allow users to register per-user keys to be used to sign messages on behalf of their affinity address. The user would take away the secret half of the key pair for signing, and the affinity domain would publish the public half in DNS for access by Verifiers. This is another application that takes advantage of user-level keying, and domains used for affinity addresses would typically have a very large number of user-level keys. Alternatively, the affinity domain could handle outgoing mail, operating a mail submission agent that authenticates users before accepting and signing messages for them. This is, of course, dependent on the user's service provider not blocking the relevant TCP ports used for mail submission.
A Forwarder that does not modify the body or signed header fields of a message is likely to maintain the validity of the existing signature. It also could choose to add its own signature to the message. Forwarders that modify a message in a way that could make an existing signature invalid are particularly good candidates for adding their own signatures (e.g., email@example.com). Since (re-)signing is taking responsibility for the content of the message, these signing forwarders are likely to be selective and forward or re-sign a message only if it is received with a valid signature or if they have some other basis for knowing that the message is not spoofed. A common practice among systems that are primarily redistributors of mail is to add a Sender header field to the message to identify the address being used to sign the message. This practice will remove any preexisting Sender header field as required by [RFC5322]. The forwarder applies a new DKIM-Signature header field with the signature, public key, and related information of the forwarder. See [RFC6377] for additional related topics and discussion.
-----BEGIN RSA PRIVATE KEY----- MIICXwIBAAKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFC jxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gb to/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB AoGBALmn+XwWk7akvkUlqb+dOxyLB9i5VBVfje89Teolwc9YJT36BGN/l4e0l6QX /1//6DWUTB3KI6wFcm7TWJcxbS0tcKZX7FsJvUz1SbQnkS54DJck1EZO/BLa5ckJ gAYIaqlA9C0ZwM6i58lLlPadX/rtHb7pWzeNcZHjKrjM461ZAkEA+itss2nRlmyO n1/5yDyCluST4dQfO8kAB3toSEVc7DeFeDhnC1mZdjASZNvdHS4gbLIA1hUGEF9m 3hKsGUMMPwJBAPW5v/U+AWTADFCS22t72NUurgzeAbzb1HWMqO4y4+9Hpjk5wvL/ eVYizyuce3/fGke7aRYw/ADKygMJdW8H/OcCQQDz5OQb4j2QDpPZc0Nc4QlbvMsj 7p7otWRO5xRa6SzXqqV3+F0VpqvDmshEBkoCydaYwc2o6WQ5EBmExeV8124XAkEA qZzGsIxVP+sEVRWZmW6KNFSdVUpk3qzK0Tz/WjQMe5z0UunY9Ax9/4PVhp/j61bf eAYXunajbBSOLlx4D+TunwJBANkPI5S9iylsbLs6NkaMHV6k5ioHBBmgCak95JGX GMot/L2x0IYyMLAz6oLWh2hm7zwtb0CgOrPo1ke44hFYnfc= -----END RSA PRIVATE KEY----- To extract the public-key component from the private key, use openssl like this: $ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM This results in the file rsa.public containing the key information 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. brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ" "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt" "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v" "/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi" "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB") RFC4870] (sometimes referred to as "selector records" in the DomainKeys context). One area of incompatibility warrants particular attention. The "g=" tag value may be used in DomainKeys and [RFC4871] key records to provide
finer granularity of the validity of the key record to a specific local-part. A null "g=" value in DomainKeys is valid for all addresses in the domain. This differs from the usage in the original DKIM specification ([RFC4871]), where a null "g=" value is not valid for any address. In particular, see the example public-key record in Section 3.2.3 of [RFC4870]. RFC4871]- compliant Verifiers will be in use for a considerable period to come.
o Several errata resolved (see http://www.rfc-editor.org/): * 1376 applied * 1377 applied * 1378 applied * 1379 applied * 1380 applied * 1381 applied * 1382 applied * 1383 discarded (no longer applies) * 1384 applied * 1386 applied * 1461 applied * 1487 applied * 1532 applied * 1596 applied o Introductory section enumerating relevant architectural documents added. o Introductory section briefly discussing the matter of data integrity added. o Allowed tolerance of some clock drift. o Dropped "g=" tag from key records. The implementation report indicates that it is not in use. o Removed errant note about wildcards in the DNS. o Removed SMTP-specific advice in most places. o Reduced (non-normative) recommended signature content list, and reworked the text in that section.
o Clarified signature generation algorithm by rewriting its pseudo- code. o Numerous terminology subsections added, imported from [RFC5672]. Also, began using these terms throughout the document (e.g., SDID, AUID). o Sections added that specify input and output requirements. Input requirements address a security concern raised by the working group (see also new sections in Security Considerations). Output requirements are imported from [RFC5672]. o Appendix subsection added discussing compatibility with DomainKeys ([RFC4870]) records. o Referred to [RFC5451] as an example method of communicating the results of DKIM verification. o Removed advice about possible uses of the "l=" signature tag. o IANA registry updated. o Added two new Security Considerations sections talking about malformed message attacks. o Various copy editing. RFC4871] was edited by Eric Allman, Jon Callas, Mark Delany, Miles Libbey, Jim Fenton, and Michael Thomas. That specification was the result of an extended collaborative effort, including participation by Russ Allbery, Edwin Aoki, Claus Assmann, Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve Bellovin, Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis Dayman, Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark Fanto, Stephen Farrell, Duncan Findlay, Elliot Gillum, Olafur Gudmundsson, Phillip Hallam-Baker, Tony Hansen, Sam Hartman, Arvel Hathcock, Amir Herzberg, Paul Hoffman, Russ Housley, Craig Hughes, Cullen Jennings, Don Johnsen, Harry Katz, Murray S. Kucherawy, Barry Leiba, John Levine, Charles Lindsey, Simon Longsdale, David Margrave, Justin Mason, David Mayne, Thierry Moreau, Steve Murphy, Russell Nelson, Dave Oran, Doug Otis, Shamim Pirzada, Juan Altmayer Pizzorno, Sanjay Pol, Blake Ramsdell, Christian Renaud, Scott Renfro, Neil
Rerup, Eric Rescorla, Dave Rossetti, Hector Santos, Jim Schaad, the Spamhaus.org team, Malte S. Stretz, Robert Sanders, Rand Wacker, Sam Weiler, and Dan Wing. The earlier DomainKeys was a primary source from which DKIM was derived. Further information about DomainKeys is at [RFC4870]. This revision received contributions from Steve Atkins, Mark Delany, J.D. Falk, Jim Fenton, Michael Hammer, Barry Leiba, John Levine, Charles Lindsey, Jeff Macdonald, Franck Martin, Brett McDowell, Doug Otis, Bill Oxley, Hector Santos, Rolf Sonneveld, Michael Thomas, and Alessandro Vesely. http://bbiw.net Tony Hansen (editor) AT&T Laboratories 200 Laurel Ave. South Middletown, NJ 07748 USA EMail: firstname.lastname@example.org Murray S. Kucherawy (editor) Cloudmark 128 King St., 2nd Floor San Francisco, CA 94107 USA EMail: email@example.com