DomainKeys Identified Mail

DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain is authorized by that domain's administrators.[1] In technical terms, DKIM is a technique to authorize a domain to associate its name to an email message through cryptographic authentication.

Verification is carried out using the signer's public key published in the DNS. A valid signature guarantees that some parts of the email (possibly including attachments) have not been modified since the signature was affixed.[2] Usually, DKIM signatures are not visible to end-users, and are affixed or verified by the infrastructure rather than message's authors and recipients. In that respect, DKIM differs from end-to-end digital signatures.[3]

History

DKIM is the result of merging two similar efforts, in 2004.[4][5] This merged specification has been the basis for a series of IETF standards-track specifications and support documents which eventually resulted in STD 76, currently RFC 6376.[6]

Aspects of DomainKeys, along with parts of Identified Internet Mail, were combined to create DomainKeys Identified Mail (DKIM),[7][8][9] which is now widely used.[5]

Trendsetting providers implementing DKIM include Yahoo, Gmail, AOL and FastMail. Any mail from these organizations should carry a DKIM signature.[7][10][11][12]

DomainKeys

DomainKeys (DK) is a deprecated email authentication method designed by Yahoo[7][13] to verify the DNS domain of an e-mail sender and the message integrity.

Both DomainKeys and DKIM were published in May 2007, DomainKeys as an "historical" protocol, and DKIM as its standards-track replacement.

Identified Internet Mail

Identified Internet Mail (IIM) was the Cisco Systems® proposed signature-based mail authentication standard.[14][15]

Development

The original DomainKeys was designed by Mark Delany of Yahoo! and enhanced through comments from many others since 2004. It is specified in Historic RFC 4870, superseded by Standards Track RFC 4871, DomainKeys Identified Mail (DKIM) Signatures; both published in May 2007. A number of clarifications and conceptualizations were collected thereafter and specified in RFC 5672, August 2009, in the form of corrections to the existing specification. In September 2011, RFC 6376 merged and updated the latter two documents, while preserving the substance of the DKIM protocol. Public key compatibility with the earlier DomainKeys is also possible.

DKIM was initially produced by an informal industry consortium and was then submitted for enhancement and standardization by the IETF DKIM Working Group, chaired by Barry Leiba and Stephen Farrell, with Eric Allman of sendmail, Jon Callas of PGP Corporation, Mark Delany and Miles Libbey of Yahoo!, and Jim Fenton and Michael Thomas of Cisco Systems attributed as primary authors.

Source code development of one common library is led by The OpenDKIM Project, following the most recent protocol additions, and licensing under the New BSD License.

Overview

DKIM provides for two distinct operations, signing and verifying. Either of them can be handled by a module of a mail transfer agent (MTA). The signing organization can be a direct handler of the message, such as the author, the submission site or a further intermediary along the transit path, or an indirect handler such as an independent service that is providing assistance to a direct handler. Signing modules insert one or more DKIM-Signature: header fields, possibly on behalf of the author organization or the originating service provider. Verifying modules typically act on behalf of the receiver organization, possibly at each hop.

The need for this type of validated identification arose because spam often has forged addresses and content. For example, a spam message may claim to be from sender@example.com, although it is not actually from that address or domain or entity, and the spammer's goal is to convince the recipient to accept and to read the email. It is difficult for recipients to establish whether to trust or distrust any particular message or even domain, and system administrators may have to deal with complaints about spam that appears to have originated from their systems but did not.[16] DKIM specification allows signers to choose which header fields they sign, but the From: field must always be signed.[17]

DKIM is independent of Simple Mail Transfer Protocol (SMTP) routing aspects in that it operates on the RFC 5322 message—the transported mail's header and body—not the SMTP envelope defined in RFC 5321. Hence the DKIM signature survives basic relaying across multiple MTAs.

DKIM allows the signer to distinguish its legitimate mail stream. It does not directly prevent or disclose abusive behavior. This ability to distinguish legitimate mail from potentially forged mail has benefits for recipients of e-mail as well as senders, and "DKIM awareness" is programmed into some e-mail software.

How it works

The DKIM-Signature header field consists of a list of tag=value parts. Tags are short, usually only one or two letters. The most relevant ones are b for the actual digital signature of the contents (headers and body) of the mail message, bh for the body hash, d for the signing domain, and s for the selector. The default parameters for the authentication mechanism are to use SHA-256 as the cryptographic hash and RSA as the public key encryption scheme, and encode the encrypted hash using Base64.

Both header and body contribute to the signature. First, the message body is hashed, always from the beginning, possibly truncated at a given length (which may be zero). Second, selected header fields are hashed, in the order given by h. Repeated field names are matched from the bottom of the header upward, which is the order in which Received: fields are inserted in the header. A non-existing field matches the empty string, so that adding a field with that name will break the signature. The DKIM-Signature: field of the signature being created, with bh equal to the computed body hash and b equal to the empty string, is implicitly added to the second hash, albeit its name must not appear in h —if it does, it refers to another, preexisting signature. For both hashes, text id canonicalized according to the relevant c algorithms. The result is b.[18] Algorithms, fields, and body length are meant to be chosen so as to assure unambiguous message identification while still allowing signatures to survive the unavoidable changes which are going to occur in transit. No data integrity is implied.[2]

The receiving SMTP server uses the domain name and the selector to perform a DNS lookup. For example, given the signature

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;
     c=relaxed/simple; q=dns/txt; l=1234; t=1117574938; x=1118006938;
     h=from:to:subject:date:keywords:keywords;
     bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
     b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
              VoG4ZHRNiYzR

A verifier queries the TXT resource record type of brisbane._domainkey.example.net. There are no CAs nor revocation lists involved in DKIM key management, and the selector is a straightforward method to allow signers to add and remove keys whenever they wish—long lasting signatures for archival purposes are outside DKIM's scope. Some more tags are visible in the example:

The data returned from the query is also a list of tag-value pairs. It includes the domain's public key, along with other key usage tokens and flags. The receiver can use this to then decrypt the hash value in the header field and at the same time recalculate the hash value for the mail message (headers and body) that was received. If the two values match, this cryptographically proves that the mail was signed by the indicated domain and has not been tampered with in transit.

Signature verification failure does not force rejection of the message. Instead, the precise reasons why the authenticity of the message could not be proven should be made available to downstream and upstream processes. Methods for doing so may include sending back an FBL message, or adding an Authentication-Results header field to the message as described in RFC 7001.

Patent encumbrance

DomainKeys is covered by U.S. Patent 6,986,049 assigned to Yahoo! Inc. For the purpose of the DKIM IETF Working Group, Yahoo! released the now obsolete DK library under a dual license scheme: the DomainKeys Patent License Agreement v1.2, an unsigned version of which can still be found,[19] and GNU General Public License v2.0 (and no other version).[20][21]

Advantages

The primary advantage of this system for e-mail recipients is it allows the signing domain to reliably identify a stream of legitimate email, thereby allowing domain-based blacklists and whitelists to be more effective.[22] This is also likely to make some kinds of phishing attacks easier to detect.

There are some incentives for mail senders to sign outgoing e-mail:

Use with spam filtering

DKIM is a method of labeling a message, and it does not itself filter or identify spam. However, widespread use of DKIM can prevent spammers from forging the source address of their messages, a technique they commonly employ today. If spammers are forced to show a correct source domain, other filtering techniques can work more effectively. In particular, the source domain can feed into a reputation system to better identify spam. Conversely, DKIM can make it easier to identify mail that is known not to be spam and need not be filtered. If a receiving system has a whitelist of known good sending domains, either locally maintained or from third party certifiers, it can skip the filtering on signed mail from those domains, and perhaps filter the remaining mail more aggressively.[22]

Anti-phishing

DKIM can be useful as an anti-phishing technology. Mailers in heavily phished domains can sign their mail to show that it is genuine. Recipients can take the absence of a valid signature on mail from those domains to be an indication that the mail is probably forged. The best way to determine the set of domains that merit this degree of scrutiny remains an open question; DKIM has an optional feature called ADSP that lets authors that sign all their mail self-identify, but the effectiveness of this approach is questionable, and ADSP was demoted to historic status in November 2013[23]

Working with eBay and PayPal, Google has effectively utilized DKIM in GMail in such a way that any e-mail that claims to be coming from ebay.com or PayPal.com will not be accepted at all if it cannot be verified successfully with DKIM. Such messages won't even appear in the Spam folder.[10] Heavily phished domains that deserve such treatment are few in number, far less than those who publish strict policies.[24]

Compatibility

Because it is implemented using DNS records and an added RFC 5322 header field, DKIM is compatible with the existing e-mail infrastructure. In particular, it is transparent to existing e-mail systems that lack DKIM support.[25]

This design approach also is compatible with other, related services, such as the S/MIME and OpenPGP content-protection standards. DKIM is compatible with the DNSSEC standard and with SPF.

Protocol overhead

DKIM requires cryptographic checksums to be generated for each message sent through a mail server, which results in computational overhead not otherwise required for e-mail delivery. This additional computational overhead is a hallmark of digital postmarks, making sending bulk spam more (computationally) expensive.[26] This facet of DKIM may look similar to hashcash, except that the receiver side verification is not a negligible amount of work.

Weaknesses

The RFC itself identifies a number of potential attack vectors.[27]

DKIM signatures do not encompass the message envelope, which holds the return-path and message recipients. Since DKIM does not attempt to protect against mis-addressing, this does not affect its utility. A concern for any cryptographic solution would be message replay abuse, which bypasses techniques that currently limit the level of abuse from larger domains . Replay can be inferred by using per-message public keys, tracking the DNS queries for those keys and filtering out the high number of queries due to e-mail being sent to large mailing lists or malicious queries by bad actors. For a comparison of different methods also addressing this problem see e-mail authentication.

Arbitrary forwarding

As mentioned above, authentication is not the same as abuse prevention. An evil email user of a reputable domain can compose a bad message and have it DKIM-signed and sent from that domain to any mailbox from where he can retrieve it as a file, so as to obtain a signed copy of the message. Use of the l tag in signatures makes doctoring such messages even easier. The signed copy can then be forwarded to a million recipients, for example through a botnet, without control. The email provider who signed the message can block the offending user, but cannot stop the diffusion of already-signed messages. The validity of signatures in such messages can be limited by always including an expiration time tag in signatures, or by revoking a public key periodically or upon a notification of an incident. Effectiveness of the scenario can hardly be limited by filtering outgoing mail, as that implies the ability to detect if a message might potentially be useful to spammers.[28]

Content modification

DKIM currently features two canonicalization algorithms, simple and relaxed, neither of which is MIME-aware.[29] Mail servers can legitimately convert to a different character set, and often document this with X-MIME-Autoconverted header fields. In addition, servers in certain circumstances have to rewrite the MIME structure, thereby altering the preamble, the epilogue, and entity boundaries, any of which breaks DKIM signatures. Only plain text messages written in us-ascii, provided that MIME header fields are not signed,[30] enjoy the robustness that end-to-end integrity requires.

The OpenDKIM Project organized a data collection involving 21 mail servers and millions of messages. 92.3% of observed signatures were successfully verified, a success rate that drops slightly (90.5%) when only mailing list traffic is considered.[31]

Annotations by mailing lists

The problems might be exacerbated when filtering or relaying software makes changes to a message. Without specific precaution implemented by the sender, the footer addition operated by most mailing lists and many central antivirus solutions will break the DKIM signature. A possible mitigation is to sign only designated number of bytes of the message body. It is indicated by l tag in DKIM-Signature header. Anything added beyond the specified length of the message body is not taken into account while calculating DKIM signature. This won't work for MIME messages.[32]

Another workaround is to whitelist known forwarders, e.g. by SPF. For yet another workaround, it was proposed that forwarders verify the signature, modify the email, and then re-sign the message with a Sender: header.[33] However, it should be noted that this solution has its risk with forwarded 3rd party signed messages received at SMTP receivers supporting the RFC 5617 ADSP protocol. Thus, in practice, the receiving server still has to whitelist known message streams.

Short key vulnerability

In October 2012, Wired reported that mathematician Zach Harris detected and demonstrated an email source spoofing vulnerability with short DKIM keys for the google.com corporate domain, as well as several other high profile domains. He stated that authentication with 384-bit keys can be factored in as little as 24 hours "on my laptop," and 512-bit keys, in about 72 hours with cloud computing resources. Harris found that many organizations sign email with such short keys; he factored them all and notified the organizations of the vulnerability. He states that 768-bit keys could be factored with access to very large amounts of computing power, so he suggests that DKIM signing should use key lengths greater than 1,024. Wired stated that Harris reported, and Google confirmed, that they began using new longer keys soon after his disclosure. According to RFC6376 the receiving party must be able to validate signatures with keys ranging from 512 bits to 2048 bits, thus usage of keys shorter than 512 bits might be incompatible and shall be avoided. The RFC6376 also states that signers must use keys of at least 1024 bits for long-lived keys, though long-livingness is not specified there.[34]

See also

References

  1. ↑ Tony Hansen; Dave Crocker; Phillip Hallam-Baker (July 2009). DomainKeys Identified Mail (DKIM) Service Overview. IETF. RFC 5585. https://tools.ietf.org/html/rfc5585. Retrieved 6 January 2016. "Receivers who successfully verify a signature can use information about the signer as part of a program to limit spam, spoofing, phishing, or other undesirable behaviors. DKIM does not, itself, prescribe any specific actions by the recipient; rather, it is an enabling technology for services that do."
  2. 1 2 Dave Crocker; Tony Hansen; Murray S. Kucherawy, eds. (September 2011). "Data Integrity". DomainKeys Identified Mail (DKIM) Signatures. IETF. sec. 1.5. RFC 6376. https://tools.ietf.org/html/rfc6376#section-1.5. Retrieved 6 January 2016. "Verifying the signature asserts that the hashed content has not changed since it was signed and asserts nothing else about "protecting" the end-to-end integrity of the message."
  3. ↑ Jim Fenton (5 January 2016). "DKIM differs from "--" first in lines to indicate start of signature". ietf-822 (Mailing list). Retrieved 5 January 2016.
  4. ↑ "DKIM Frequently Asked Questions". DKIM.org. 16 October 2007. Retrieved 4 January 2016. DKIM was produced by an industry consortium in 2004. It merged and enhanced DomainKeys, from Yahoo! and Identified Internet Mail, from Cisco.
  5. 1 2 Jim Fenton (15 June 2009). "DomainKeys Identified Mail (DKIM) Grows Significantly". Cisco. Retrieved 28 October 2014.
  6. ↑ "STD 76, RFC 6376 on DomainKeys Identified Mail (DKIM) Signatures". IETF. 11 July 2013. Retrieved 12 July 2013. RFC 6376 has been elevated to Internet Standard.
  7. 1 2 3 Delany, Mark (May 22, 2007). "One small step for email, one giant leap for Internet safety". Yahoo! corporate blog. Delany is credited as Chief Architect, inventor of DomainKeys.
  8. ↑ RFC 4870 ("Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)"; obsoleted by RFC 4871).
  9. ↑ RFC 6376 ("DomainKeys Identified Mail (DKIM) Signatures"; obsoletes RFC 4871 and RFC 5672).
  10. 1 2 Taylor, Brad (July 8, 2008). "Fighting phishing with eBay and Paypal". Gmail Blog.
  11. ↑ "I’m having trouble sending messages in Gmail". Gmail Help entry, mentioning DKIM support when sending.
  12. ↑ Mueller, Rob (August 13, 2009). "All outbound email now being DKIM signed". Fastmail blog.
  13. ↑ "May 19, 2004 Yahoo Releases Specs for DomainKeys"
  14. ↑ "Identified Internet Mail: A network based message signing approach to combat email fraud". 26 April 2006. Archived from the original on 27 April 2006. Retrieved 4 January 2016.
  15. ↑ Jim Fenton; Michael Thomas (1 June 2004). Identified Internet Mail. IETF. I-D draft-fenton-identified-mail-00. https://tools.ietf.org/html/draft-fenton-identified-mail-00. Retrieved 6January 2016.
  16. ↑ Jason P. Stadtlander (16 January 2015). "Email Spoofing: Explained (and How to Protect Yourself)". HuffPost. Retrieved 11 January 2016.
  17. ↑ Dave Crocker; Tony Hansen; Murray S. Kucherawy, eds. (July 2009). "Determine the Header Fields to Sign". DomainKeys Identified Mail (DKIM) Signatures. IETF. sec. 5.4. RFC 6376. https://tools.ietf.org/html/rfc6376#section-5.4. Retrieved 6 January 2016. "The From header field MUST be signed (that is, included in the "h=" tag of the resulting DKIM-Signature header field)."
  18. ↑ Dave Crocker; Tony Hansen; Murray S. Kucherawy, eds. (September 2011). "Computing the Message Hashes". DomainKeys Identified Mail (DKIM) Signatures. IETF. sec. 3.7. RFC 6376. https://tools.ietf.org/html/rfc6376#section-3.7. Retrieved 18 January 2016.
  19. ↑ "Yahoo! DomainKeys Patent License Agreement v1.1". SourceForge. 2006. Retrieved 2010-05-30. Yahoo! DomainKeys Patent License Agreement v1.2
  20. ↑ Levine, John R. (January 25, 2010). "IPR disclosures, was Collecting re-chartering questions". ietf-dkim mailing list. Mutual Internet Practices Association. Retrieved 2010-05-30. The reference to the GPL looks to me like it only covers the old Sourceforge DK library, which I don't think anyone uses any more. The patent, which is what's important, is covered by a separate license that Yahoo wrote.
  21. ↑ Chen, Andy (September 26, 2011). "Yahoo! Inc.'s Statement about IPR related to RFC 6376". IPR disclosure. IETF. Retrieved 3 October 2011.
  22. 1 2 Falk, J.D. (March 17, 2009). "Searching for Truth in DKIM". CircleID.
  23. ↑ Barry Leiba (2013-11-25). "Change the status of ADSP (RFC 5617) to Historic". IETF. Retrieved 13 March 2015.
  24. ↑ John Levine (2 June 2010). "shared drop lists". IETF DKIM Discussion List. mipassoc. Retrieved 1 July 2013. At this point my published drop list contains PayPal domains, who publish ADSP, and eBay and Amazon who don't publish ADSP, but who send transaction mail all of which is as far as I can tell signed.
  25. ↑ Tony Hansen; Dave Crocker; Phillip Hallam-Baker (July 2009). DomainKeys Identified Mail (DKIM) Service Overview. IETF. RFC 5585. https://tools.ietf.org/html/rfc5585. Retrieved 1 July 2013.
  26. ↑ Roic, Alessio (July 5, 2007). "Postmarking: helping the fight against spam". Microsoft Office Outlook Blog.
  27. ↑ "Security considerations", ietf.org
  28. ↑ Jim Fenton (September 2006). "Chosen Message Replay". Analysis of Threats Motivating DomainKeys Identified Mail (DKIM). IETF. sec. 4.1.4. RFC 4686. https://tools.ietf.org/html/rfc4686#section-4.1.4. Retrieved 10 January 2016.
  29. ↑ Ned Freed (with agreement by John Klensin) (March 5, 2010). "secdir review of draft-ietf-yam-rfc1652bis-03". YAM mailing list. IETF. Retrieved 2010-05-30. DKIM WG opted for canonical form simplicity over a canonical form that's robust in the face of encoding changes. It was their engineering choice to make and they made it.
  30. ↑ RFC 2045 allows a parameter value to be either a token or a quoted-string, e.g. in format="flowed" the quotes can be legally removed, which breaks DKIM signatures.
  31. ↑ Kucherawy, Murray (March 28, 2011). "RFC4871 Implementation Report". IETF. Retrieved 2012-02-18.
  32. ↑ Murray S. Kucherawy (September 2011). DomainKeys Identified Mail (DKIM) and Mailing Lists. IETF. RFC 6377. https://tools.ietf.org/html/rfc6377. Retrieved 10 January 2016.
  33. ↑ Eric Allman; Mark Delany; Jim Fenton (August 2006). "Mailing List Manager Actions". DKIM Sender Signing Practices. IETF. sec. 5.1. I-D draft-allman-dkim-ssp-02. https://tools.ietf.org/html/draft-allman-dkim-ssp-02#section-5.1. Retrieved 10 January 2016.
  34. ↑ Zetter, Kim (October 24, 2012). "How a Google Headhunter’s E-Mail Unraveled a Massive Net Security Hole". Wired. Accessed October 24, 2012.

Notes

    Further reading

    External links

    External links to online tools

    External links to implementations and howtos

    This article is issued from Wikipedia - version of the Monday, February 15, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.