RFC 4686
Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)
Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) 💖
okay bestie, this is RFC 4686, and it's written by J. Fenton from Cisco Systems, Inc. 🎀 It's dated September 2006 and its category is Informational, which means it's sharing info with the Internet community and isn't an actual standard. It lives in the Network Working Group stream. The title block doesn't list anything it obsoletes or updates, so there's no drama there ✨
Status of This Memo 🌸
this memo is just providing info for the Internet community. it does not specify an Internet standard of any kind, and distribution of it is unlimited 🫶
Copyright Notice 📜
Copyright (C) The Internet Society (2006).
Abstract 🦋
okay so this doc looks at some threats against Internet mail that signature-based mail authentication is meant to handle, specifically DomainKeys Identified Mail. it talks about who the bad actors are, where they're hiding, what they can do, and what they're trying to pull off with their attacks 👀
Table of Contents 💜
1. Introduction ....................................................3
1.1. Terminology and Model ......................................3
1.2. Document Structure .........................................5
2. The Bad Actors ..................................................6
2.1. Characteristics ............................................6
2.2. Capabilities ...............................................6
2.3. Location ...................................................8
2.3.1. Externally-Located Bad Actors .......................8
2.3.2. Within Claimed Originator's Administrative Unit .....8
2.3.3. Within Recipient's Administrative Unit ..............9
3. Representative Bad Acts .........................................9
3.1. Use of Arbitrary Identities ................................9
3.2. Use of Specific Identities ................................10
3.2.1. Exploitation of Social Relationships ...............10
3.2.2. Identity-Related Fraud .............................11
3.2.3. Reputation Attacks .................................11
3.2.4. Reflection Attacks .................................11
4. Attacks on Message Signing .....................................12
4.1. Attacks against Message Signatures ........................12
4.1.1. Theft of Private Key for Domain ....................13
4.1.2. Theft of Delegated Private Key .....................13
4.1.3. Private Key Recovery via Side Channel Attack .......14
4.1.4. Chosen Message Replay ..............................14
4.1.5. Signed Message Replay ..............................16
4.1.6. Denial-of-Service Attack against Verifier ..........16
4.1.7. Denial-of-Service Attack against Key Service .......17
4.1.8. Canonicalization Abuse .............................17
4.1.9. Body Length Limit Abuse ............................17
4.1.10. Use of Revoked Key ................................18
4.1.11. Compromise of Key Server ..........................18
4.1.12. Falsification of Key Service Replies ..............19
4.1.13. Publication of Malformed Key Records
and/or Signatures .................................19
4.1.14. Cryptographic Weaknesses in Signature Generation ..20
4.1.15. Display Name Abuse ................................21
4.1.16. Compromised System within Originator's Network ....21
4.1.17. Verification Probe Attack .........................21
4.1.18. Key Publication by Higher-Level Domain ............22
4.2. Attacks against Message Signing Practices .................23
4.2.1. Look-Alike Domain Names ............................23
4.2.2. Internationalized Domain Name Abuse ................23
4.2.3. Denial-of-Service Attack against Signing
Practices ..........................................24
4.2.4. Use of Multiple From Addresses .....................24
4.2.5. Abuse of Third-Party Signatures ....................24
4.2.6. Falsification of Sender Signing Practices Replies ..25
4.3. Other Attacks .............................................25
4.3.1. Packet Amplification Attacks via DNS ...............25
5. Derived Requirements ...........................................26
6. Security Considerations ........................................26
7. Informative References .........................................27
Appendix A. Acknowledgements ......................................281. Introduction ✨
okay so the DomainKeys Identified Mail (DKIM) protocol is being specified by the IETF DKIM Working Group 🧚 it gives email messages a way to get cryptographically signed, so a signing domain can claim responsibility for using a particular email address. recipients can verify the signature by asking the signer's domain directly for the right public key. that way they can confirm the message was vouched for by someone holding the private key for that signing domain 🔐 this doc is about threats to two works in progress from the DKIM Working Group: the DKIM signature spec [DKIM-BASE] and DKIM Sender Signing Practices [DKIM-SSP] 💅
once the attesting party or parties are established, the recipient can judge the message using extra info like locally-maintained whitelists, shared reputation services, and/or third-party accreditation. describing those mechanisms is outside the scope of the DKIM Working Group, so that's not this doc's job 🙈 the vibe is that by signing a message, a good player helps the verifier give that message a positive reputation, hoping it gets preferential treatment from the recipient. main character energy 👑
this effort is NOT about message confidentiality, and it's also not trying to provide a long-term archival signature. just so we're clear 🫶
1.1. Terminology and Model 🦋
an administrative unit (AU) is the part of an email message's path that's under common administration. originators and recipients usually build trust with the AUs that send and receive their mail, so those AUs can do the signing and verifying 🌈
the origin address is the address on an email message, usually the RFC 2822 From: address. it's tied to the alleged author and it's the one the recipient's Mail User Agent (MUA) shows as where the message came from 💌
here's a usual DKIM flowchart so you can picture it 🎀
+---------------------------------+
| SIGNATURE CREATION |
| (Originating or Relaying AU) |
| |
| Sign (Message, Domain, Key) |
| |
+---------------------------------+
| - Message (Domain, Key)
|
[Internet]
|
V
+---------------------------------+
+-----------+ | SIGNATURE VERIFICATION |
| | | (Relaying or Delivering AU) |
| KEY | | |
| QUERY +--->| Verify (Message, Domain, Key) |
| | | |
+-----------+ +----------------+----------------+
| - Verified Domain
+-----------+ V - [Report]
| SENDER | +----------------+----------------+
| SIGNING | | |
| PRACTICES +--->| SIGNER EVALUATION |
| QUERY | | |
| | +---------------------------------+
+-----------+DKIM works entirely on the content of the message (the body and selected header fields), as defined in RFC 2822 [RFC2822] 📨 the transmission over SMTP, defined in RFC 2821 [RFC2821], plus stuff like the envelope-from and envelope-to addresses and the HELO domain, are NOT relevant to DKIM verification. this was a deliberate choice so messages can be verified over protocols other than SMTP, like POP [RFC1939] and IMAP [RFC3501], which an MUA acting as a verifier might use 🧚
the Sender Signing Practices Query from the diagram above is how a verifier can ask the alleged author's domain what its signing practices are. that info can change how the verifier evaluates the message 🔍 for example, say a message shows up with no valid signatures, and the author's domain advertises that it signs all messages. the verifier might handle that message differently than if a signature wasn't necessarily expected 💀
1.2. Document Structure 🌸
the rest of this doc is about the problems DKIM might be expected to address, and how far it might succeed. those get described through the potential bad actors, what they can do, where they sit in the network, and the bad acts they might want to commit ✨
after that, there's a description of postulated attacks on DKIM message signing, plus attacks on using Sender Signing Practices to help treat unsigned messages. there's also a list of derived requirements meant to guide the DKIM design and review process 🫶
the sections on DKIM attacks each start with a table summarizing the postulated attacks in each category, along with their expected impact and likelihood. these were the rough criteria used for scoring the attacks 📊
- Impact:
- High: affects the verification of messages from an entire domain or multiple domains
- Medium: affects the verification of messages from specific users, Mail Transfer Agents (MTAs), and/or bounded time periods
- Low: affects the verification of isolated individual messages only
- Likelihood:
- High: all email users should expect this attack on a frequent basis
- Medium: email users should expect this attack occasionally; frequently for a few users
- Low: attack is expected to be rare and/or very infrequent
2. The Bad Actors 😈
part 2 picks up right here with the bad actors, so stay tuned 🧚💜
2.1. Characteristics 🎀
okay so the problem space DKIM is trying to solve has a WIDE range of attackers, and they're all different in how motivated they are, how sophisticated they are, and what they can do 💅
At the low end, you've got bad actors who just send email. Like, whatever, they grab one of the many commercially available tools and blast stuff the recipient really doesn't want 🙄. These tools usually let you falsify the origin address of messages, and they might be able to generate message signatures too someday 👀
Next tier up: the "professional" senders of unwanted email 💼. These folks deploy real infrastructure, including Mail Transfer Agents (MTAs), registered domains, and networks of compromised computers ("zombies") to send messages, and sometimes to harvest addresses to send to as well. They often run as commercial enterprises and send messages on behalf of third parties. Business, ugh 😤
Then there are the most sophisticated and financially motivated senders, the ones who stand to get a LOT of money, like from an email-based fraud scheme 🤑. These attackers can be expected to use all of the above mechanisms, and they may also go after the Internet infrastructure itself, including DNS cache-poisoning attacks and IP routing attacks. Villain arc, fr 😭
2.2. Capabilities 🦋
In general, the bad actors we just talked about should be expected to have access to the following:
- An extensive corpus of messages from domains they might wish to impersonate
- Knowledge of the business aims and model for domains they might wish to impersonate
- Access to public keys and associated authorization records associated with the domain
and the ability to do at least some of the following:
- Submit messages to MTAs and Message Submission Agents (MSAs) at multiple locations in the Internet
- Construct arbitrary message header fields, including those claiming to be mailing lists, resenders, and other mail agents
- Sign messages on behalf of domains under their control
- Generate substantial numbers of either unsigned or apparently-signed messages that might be used to attempt a denial-of-service attack
- Resend messages that may have been previously signed by the domain
- Transmit messages using any envelope information desired
- Act as an authorized submitter for messages from a compromised computer
As noted above, certain classes of bad actors may have substantial financial motivation for their activities, so they should be expected to have more capabilities at their disposal 🧠 These include:
- Manipulation of IP routing. This could be used to submit messages from specific IP addresses or difficult-to-trace addresses, or to cause diversion of messages to a specific domain.
- Limited influence over portions of DNS using mechanisms such as cache poisoning. This might be used to influence message routing or to falsify advertisements of DNS-based keys or signing practices.
- Access to significant computing resources, for example, through the conscription of worm-infected "zombies" computers. This could allow the bad actor to perform various types of brute-force attacks.
- Ability to eavesdrop on existing traffic, perhaps from a wireless network.
Either of the first two of these mechanisms could be used to let the bad actor function as a man-in-the-middle between author and recipient, if that attack is useful 🫣
2.3. Location 📍
Bad actors, or their proxies, can be located anywhere in the Internet 🌍 Certain attacks are possible primarily within the administrative unit of the claimed originator and/or recipient domain, and bad actors there have capabilities beyond those elsewhere, as described in the below sections. Bad actors can also collude by acting from multiple locations (a "distributed bad actor") 👯
It should also be noted that, with the use of "zombies" and other proxies, externally-located bad actors may gain some of the capabilities of being located within the claimed originator's or recipient's administrative unit. This is why appropriate security measures, such as authenticated submission of messages, matter even within administrative units 🔐
2.3.1. Externally-Located Bad Actors
DKIM focuses primarily on bad actors located outside of the administrative units of the claimed originator and the recipient. These administrative units frequently correspond to the protected portions of the network adjacent to the originator and recipient. This is the area where the trust relationships required for authenticated message submission do not exist and do not scale adequately to be practical 🙃 On the flip side, inside these administrative units there are other mechanisms, such as authenticated message submission, that are easier to deploy and more likely to be used than DKIM.
External bad actors are usually trying to exploit the "any to any" nature of email, which motivates most recipient MTAs to accept messages from anywhere for delivery to their local domain 📬 They may generate messages without signatures, with incorrect signatures, or with correct signatures from domains with little traceability. They may also pose as mailing lists, greeting cards, or other agents that legitimately send or resend messages on behalf of others 🎭
2.3.2. Within Claimed Originator's Administrative Unit
Bad actors in the form of rogue or unauthorized users, or malware-infected computers, can exist within the administrative unit corresponding to a message's origin address 👀 Since submission of messages in this area generally occurs before a message signature is applied, DKIM is not directly effective against these bad actors. Defense against them depends on other means, such as proper use of firewalls and Message Submission Agents that are configured to authenticate the author 🛡️
In the special case where the administrative unit is non-contiguous (for example, a company that communicates between branches over the external Internet), DKIM signatures can be used to tell apart legitimate externally-originated messages from attempts to spoof addresses in the local domain 🧩
2.3.3. Within Recipient's Administrative Unit
Bad actors may also exist within the administrative unit of the message recipient. These bad actors may try to exploit the trust relationships that exist within the unit 😈 Since messages will typically only have undergone DKIM verification at the administrative unit boundary, DKIM is not effective against messages submitted in this area.
For example, the bad actor may try to spoof a header field indicating the results of verification. This header field would normally be added by the verifier, which would also detect spoofed header fields on messages it was attempting to verify. Spoofing it could be used to falsely indicate that the message was authenticated successfully 🙈
As in the originator case, these bad actors can be dealt with by controlling the submission of messages within the administrative unit. Since DKIM permits verification to occur anywhere within the recipient's administrative unit, these threats can also be minimized by moving verification closer to the recipient, such as at the Mail Delivery Agent (MDA) or on the recipient's MUA itself 💖
3. Representative Bad Acts ✨
One of the most fundamental bad acts being attempted is the delivery of messages that are not intended to have been sent by the alleged originating domain. As described above, these messages might merely be unwanted by the recipient, or they might be part of a confidence scheme or a delivery vector for malware 🦠
3.1. Use of Arbitrary Identities 🎭
This class of bad acts includes sending messages that aim to obscure the identity of the actual author. In some cases the actual sender might be the bad actor, and in other cases it might be a third party under the control of the bad actor (for example, a compromised computer) 💀
Particularly when coupled with sender signing practices that indicate the domain owner signs all messages, DKIM can be effective at mitigating the abuse of addresses not controlled by bad actors 🙌 DKIM is not effective against the use of addresses controlled by bad actors. In other words, the presence of a valid DKIM signature does not guarantee that the signer is not a bad actor. It also does not guarantee the accountability of the signer, since DKIM does not attempt to identify the signer individually, but rather identifies the domain that they control 🧐 Accreditation and reputation systems, along with locally-maintained whitelists and blacklists, can be used to enhance the accountability of DKIM-verified addresses and/or the likelihood that signed messages are desirable.
3.2. Use of Specific Identities 🎯
A second major class of bad acts involves asserting specific identities in email.
Note that some bad acts involving specific identities can sometimes be accomplished, although perhaps less effectively, with similar-looking identities that mislead some recipients 👓 For example, if the bad actor is able to control the domain examp1e.com (note the "one" between the p and e), they might be able to convince some recipients that a message from admin@examp1e.com is really from admin@example.com. Similar types of attacks using internationalized domain names have been hypothesized, where it could be very difficult to see character differences in popular typefaces. Similarly, if example2.com was controlled by a bad actor, the bad actor could sign messages from bigbank.example2.com, which might also mislead some recipients. To the extent that these domains are controlled by bad actors, DKIM is not effective against these attacks, although it could support the ability of reputation and/or accreditation systems to help the user identify them 🕵️♀️
DKIM is effective against the use of specific identities only when there is an expectation that such messages will, in fact, be signed. The primary means for establishing this is the use of Sender Signing Practices (SSP), which will be specified by the IETF DKIM Working Group 📋
3.2.1. Exploitation of Social Relationships
One reason for asserting a specific origin address is to encourage a recipient to read and act on particular email messages by appearing to be an acquaintance or previous correspondent that the recipient might trust 🥹 This tactic has been used by email-propagated malware that mails itself to addresses in the infected host's address book. In this case, however, the author's address may not be falsified, so DKIM would not be effective in defending against this act.
It is also possible for address books to be harvested and used by an attacker to post messages from elsewhere. DKIM could be effective in mitigating these acts by limiting the scope of origin addresses for which a valid signature can be obtained when sending messages from other locations 🔒
3.2.2. Identity-Related Fraud 💌
okay so email fraud is lowkey about sending messages from somebody else's real origin address 🫣. not every scheme does this, but a lot of them do! using a specific address can really help the fraud work, because the recipient is more likely to believe the message came from the person it claims to be from 🎭.
bestie, here's the spicy part 🌶️. if the scheme's success depends on or gets a boost from using a specific origin address, the bad actor might have serious money and resources to get around whatever protections exist for those addresses. yikes 😭.
DKIM is actually a good defense here 🛡️. when signatures get verified by or for the recipient, DKIM works against fraudulent use of origin addresses on signed messages ✅. and if the published sender signing practices for an origin address say that all messages from it should be signed, DKIM also helps against attempted fraud using that address on unsigned messages 💅.
3.2.3. Reputation Attacks 😈
another reason somebody might use a specific origin address is to ruin another person's reputation 💀. this is commonly called a "joe-job" 🙈. picture a business trying to tank a competitor by sending unsolicited bulk email as if it came from that competitor. messy! 😤 this is exactly why reputation systems need to be built on an identity that is, in practice, pretty reliable 🔒.
3.2.4. Reflection Attacks 🪞
a super common trick for some bad actors is sending messages indirectly. they deliberately mis-address the message so it gets "bounced", meaning it's sent to the return address (the RFC 2821 envelope-from address) on the message 📬. in this case, the specific identity shown in the email is that of the real target, the one the message is "returned" to 😵💫.
here's the tea ☕. DKIM doesn't generally try to validate the RFC2821.mailfrom return address on messages. that's true whether you look at it directly (the mailfrom address is part of the SMTP protocol, not the message content DKIM operates on) or through the optional Return-Path header field 📭. also, as Section 4.4 of RFC 2821 [RFC2821] points out, it's a common and useful practice for a message's return path not to match the origin address 🔄. so for these reasons, DKIM is not effective against reflection attacks 🙅♀️.
4. Attacks on Message Signing 🕵️♀️
bestie, bad actors can be expected to exploit every limitation of message authentication systems 🥷. they're also likely to be motivated to make message authentication systems less useful so they're harder to deploy 📉. both the signature mechanism itself and the declarations made about using message signatures (called Sender Signing Practices, or SSP here) can be expected to be targets of attacks 🎯.
4.1. Attacks against Message Signatures 🔐
okay here's the summary of postulated attacks against DKIM signatures 📋:
+---------------------------------------------+--------+------------+
| Attack Name | Impact | Likelihood |
+---------------------------------------------+--------+------------+
| Theft of private key for domain | High | Low |
| Theft of delegated private key | Medium | Medium |
| Private key recovery via side channel attack| High | Low |
| Chosen message replay | Low | M/H |
| Signed message replay | Low | High |
| Denial-of-service attack against verifier | High | Medium |
| Denial-of-service attack against key service| High | Medium |
| Canonicalization abuse | Low | Medium |
| Body length limit abuse | Medium | Medium |
| Use of revoked key | Medium | Low |
| Compromise of key server | High | Low |
| Falsification of key service replies | Medium | Medium |
| Publication of malformed key records and/or | High | Low |
| signatures | | |
| Cryptographic weaknesses in signature | High | Low |
| generation | | |
| Display name abuse | Medium | High |
| Compromised system within originator's | High | Medium |
| network | | |
| Verification probe attack | Medium | Medium |
| Key publication by higher-level domain | High | Low |
+---------------------------------------------+--------+------------+4.1.1. Theft of Private Key for Domain 🗝️
message signing tech like DKIM is vulnerable to theft of the private keys used to sign messages 😱. that includes "out-of-band" methods like burglary, bribery, extortion, and so on 🦹♀️. it also includes electronic methods, like compromising the network and host security around wherever the private key is stored 💻.
keys that are valid for all addresses in a domain usually live in MTAs, and those should be located in well-protected sites, like data centers 🏰. various means should be used to minimize access to private keys, like having no commands that display their value. but ngl, memory dumps and the like will probably still contain the keys 🫠. because MTAs are unattended, some countermeasures, like using a pass phrase to "unlock" a key, aren't practical 🙃. dedicated hardware devices that hold the private key and do the cryptographic signature operation would be super effective at stopping export of the key to anyone without physical access to the device 🔥. those devices would almost certainly make the theft of the key visible, so appropriate action (revoking the corresponding public key) can be taken if it ever happens 🚨.
4.1.2. Theft of Delegated Private Key 🎁
there are lots of situations where a domain owner wants to delegate the ability to sign messages for the domain to an individual user or a third party tied to an outsourced activity, like a corporate benefits administrator or a marketing campaign 📣. these keys might live on less well-protected devices than the domain's own MTAs, so in many cases they're more open to compromise 😬.
to lower that exposure, the domain owner can restrict keys used to sign these messages so they're only valid for signing messages on behalf of specific addresses in the domain 🎯. that way, most of the addresses in the domain stay protected 🛡️.
there's also a related threat: exploiting weaknesses in the delegation process itself 🧐. customary precautions against theft of private keys and falsification of public keys in transit can help with this 🔑. for example, exposure to theft goes down if the delegate generates the keypair and sends the public key to the domain owner 📤. and exposure to falsification (swapping in a different public key) goes down if that transmission is signed by the delegate and verified by the domain owner ✍️.
4.1.3. Private Key Recovery via Side Channel Attack 🧪
all popular digital signature algorithms are subject to a bunch of side channel attacks 🌀. the most well-known are timing channels [Kocher96], power analysis [Kocher99], and cache timing analysis [Bernstein04] 📊. most of these attacks need either physical access to the machine or the ability to run processes directly on the target machine 🖥️. defending against these attacks is out of scope for DKIM 🙅♀️.
remote timing analysis is a different story 👀. at least on local area networks, it's known to be feasible [Boneh03] 🌐. it's especially a thing on server-type platforms, where an attacker can inject traffic that will immediately be subject to the cryptographic operation in question 💥. with enough samples, these techniques can extract private keys even when the timing measurements have modest amounts of noise 🫣.
the three commonly proposed countermeasures against timing analysis are 📝:
- Make the operation run in constant time. In practice this turns out to be rather difficult.
- Make the time independent of the input data. This can be difficult, but see [Boneh03] for more details.
- Use blinding. This is generally considered the best current practice countermeasure. It's not proved generally secure, but it is a countermeasure against known timing attacks ✨. it adds about 2-10% to the cost of the operation, and it's implemented in many common cryptographic libraries 📚. unfortunately, Digital Signature Algorithm (DSA) and Elliptic Curve DSA (ECDSA) don't have standard methods, though some defenses may exist 😤.
note that adding random delays to the operation is only a partial countermeasure 🚫. because the noise is generally uniformly distributed, a large enough number of samples can be used to average it out and extract an accurate timing signal 📉.
4.1.4. Chosen Message Replay 💌
okay so chosen message replay is when the attacker makes a message, then gets it signed by sending it through an MTA that the originating domain authorizes, and they send it to themselves or an accomplice 🕵️♀️. Then they "replay" that signed message, using different envelope addresses, to a (usually huge) pile of other recipients 📬💀.
This one would mostly hit consumer ISPs or anyone else handing out email accounts to clients 🫶. Why? Because the attacker has to get their own message signed, and the account holder (the attacker, in this case) basically has zero accountability 🙈. One fix is for the domain to only sign email for clients who went through a vetting process, so there's traceability back to the message originator if things go sideways 🔍. But rn email accounts cost nothing (zero!), so vetting just isn't practical 😭. We'll have to see if signed mail goes this same route, or if you'll need a higher level of trust before you can get an email signature 🤔✨.
There's also a twist where the attacker sends a message on purpose so they get a signed reply that contains their original message 🎭. The reply could come from an innocent user, or it could be an automatic response like a "user unknown" bounce message 🤖. Sometimes that signed reply can actually get the attacker what they want if they replay it 😈. You can make this variation way less effective by limiting how much of the original content gets quoted in automatic replies, and by using other stuff like egress content filtering too 🛡️💅.
Revoking the signature or the key tied to it is a possible countermeasure 🔑. BUT the replay can happen super fast (especially with an army of "zombie" computers 🧟), and detecting the attack and getting the revocation done takes way longer, so that's gonna be a problem 😩. Another thing: domains often use a small number of signing keys for a big number of customers. That's great for caching 💖, but if a key gets revoked suddenly, you'll get a ton of collateral damage in the form of signature verification failures 💥.
Revoking per signature would fix the collateral damage problem, but it needs some serious scaling 📈. At the extreme, verifiers would have to check for revocation of every single signature they verify, and the transaction rates would be absolutely wild 🥵. An alternative called "revocation identifiers" has been proposed 🎀. It would let you revoke at a middle level of granularity, maybe per account 👑. Messages with these identifiers would trigger a query to a revocation database, which could be represented in DNS 🌐.
Whether the benefits of revocation (given how fast a replay attack can move) are worth the transactional cost of querying a revocation database still needs more study 📚🔬.
4.1.5. Signed Message Replay 🔁
signed message replay is when already-signed messages get retransmitted to more recipients than the author or original poster meant to send them to 📨. The attacker gets a message from the victim, then sends it along exactly as is, just with different envelope addresses 🎯. They might do this to make it look like a legit sender is blasting out a huge amount of spam 🗑️. If reputation services are in use, this could hurt the author's reputation, or the reputation of the author's domain 💔.
More domains can be victims of signed message replay than chosen message replay, because the attacker doesn't need to be able to send messages from the victim domain 🌍. BUT the attacker's capabilities are weaker 🥲. Unless it's paired with another attack like body length limit abuse, the attacker can't really use this for advertising 🙅♀️.
Lots of mailing lists engage in a version of signed message replay 📬🫶. Especially the ones that don't change the message content or the signed header fields, so the signature stays valid 💅. Body length limits and other ways of making messages more likely to survive also make this easier to pull off ✨. The only thing that separates this from the bad kind of signed message replay is the intent of the replayer, and the network can't figure that out 🤷♀️.
4.1.6. Denial-of-Service Attack against Verifier 🚫
Signing and verifying a signature takes some computing resources, but generating an invalid signature takes basically nothing 🥱. So an attacker could run a "make work" attack on a verifier by flooding it with a ton of incorrectly signed messages, maybe with multiple signatures on each one 🌊. The goal is to make verifying messages too expensive 💸.
This attack is totally doable, but how the verifier operates can seriously lessen the damage 🛡️✨. For example, it could decide to only accept a certain number of signatures per message, cap the maximum key size it'll accept (so huge signatures can't create extra work), and verify signatures in a specific order 🔢. The verifier could also keep track of its current signature verification failure rate and go into a defensive mode when attacks might be happening 🚨🦋.
4.1.7. Denial-of-Service Attack against Key Service 🔑💥
An attacker might also try to make an originator's key service less available, so that the originator's messages can't be verified 😵. One way to do that is to quickly send a ton of messages with signatures that reference one particular key, which puts a heavy load on the key server 🏋️♀️. There are also other kinds of DoS attacks on the key server, or on the network infrastructure serving it 🌐.
The best defense is redundant key servers, ideally in geographically separate parts of the Internet 🌏💖. Caching helps a ton too, since it takes pressure off authoritative key servers when lots of key requests come in at once 🧠. Using a key service protocol that keeps the transactional cost of key lookups low is also a big win 🏆. And the Domain Name System has all of these characteristics, which is iconic 👑🌸.
4.1.8. Canonicalization Abuse 🧩
Canonicalization algorithms are all about balancing two things: keeping a message signature valid even when the message gets a little changed, and not letting the message be altered in inappropriate ways ⚖️. In the past, some canonicalization algorithms were proposed that could have let attackers change the meaning of a message in certain cases 😱.
Message signatures that support multiple canonicalization algorithms let the signer choose how much they care about signature survivability versus immutability of the signed content 🎛️. If an unexpected vulnerability shows up in a canonicalization algorithm that people are using a lot, new algorithms can be deployed 🚀. But that's a slow process, because the signer can never be sure which algorithms the verifier supports 🐢. That's why canonicalization algorithms, just like cryptographic algorithms, should go through a wide and careful review process 🔍🫶.
4.1.9. Body Length Limit Abuse 📏
A body length limit is an optional hint from the signer about how much content was actually signed ✍️. The verifier can ignore the limit, verify just the specified portion of the message, or truncate the message to the specified portion and then verify it 🎀. This feature exists because lots of mailing lists add a trailer (often identifying the list) to the end of messages 📮.
When body length limits are used, an attacker could potentially add content to the message 😈. It's been shown that this added content, even though it's at the end, can cover up desirable content, especially in HTML messages 🙈🖼️.
If the body length isn't specified, or the verifier decides to ignore the limit, body length limits are moot 🙌. If the verifier or recipient truncates the message at the signed content, the attacker has no chance to add anything 🙅♀️.
If the verifier does observe body length limits when they're present, an attacker could potentially make undesired content visible to the recipient 👀. The size of the appended content doesn't matter much, since it can just be a URL reference pointing to the real content 🔗. Receiving MUAs can reduce this threat by, at minimum, identifying the unsigned content in the message 🏷️✨.
4.1.10. Use of Revoked Key 🗝️❌
Caching key records is great, but it opens the door to keys that have already been revoked still being used for some time after the revocation 😬. The most obvious example is when someone holding a key the domain administrator delegated has to be unexpectedly deauthorized from sending mail on behalf of one or more addresses in the domain 🚫📧.
Caching of key records is normally short-lived, somewhere between hours and days ⏳. In lots of cases, you can mitigate this threat just by setting a short time-to-live (TTL) for keys that the domain administrator doesn't directly control 🕰️. (This assumes the TTL can be specified for each record, which it can be with DNS 🌐.) In some cases, like recovering after a stolen private key belonging to one of the domain's MTAs, you need to weigh the possibility of theft and how much effort it takes to revoke the key authorization when you pick a TTL 🧐. The chosen TTL has to be long enough to mitigate denial-of-service attacks and provide reasonable transaction efficiency, and no longer 💅💜.
4.1.11. Compromise of Key Server 🔑
okay so, instead of trying to steal a private key, an attacker could go after the server that publishes a domain's public keys 👀. The goal is the same as key theft: signing mail as the domain 📨. But this attack gives them an extra power too, because they can remove legit keys from publication, so the domain's signatures stop verifying properly 💀.
To limit signing to people the domain owner actually authorized, there has to be a link between the signing address and the place the verifier fetches the public key from 🧵. DKIM does this by publishing either the public key or a pointer to it in the DNS hierarchy of the signing domain. The verifier figures out where to look from the signing address or domain. So the security of verification is only as strong as the DNS hierarchy for the signing domain 🥺.
An attacker could compromise the host that's the primary key server for the signing domain, like the domain's DNS master server 😬. Or they could go higher up, compromise a higher-level DNS server, and switch the name server delegation for the signing domain over to servers they control 🚨.
This can be softened a bit with independent monitoring to audit the key service 🕵️♀️. The auditing should happen through zone transfers instead of queries to the zone's primary server, so that any records added to the zone can actually be spotted 🔍✨.
4.1.12. Falsification of Key Service Replies 🎭
Replies from the key service can also be spoofed by an attacker who's in a good spot on the network 😈. For DNS, one way to do this is "cache poisoning", where the attacker slips unnecessary (and wrong) extra info into DNS replies, and that junk gets cached 🗑️.
DNSSEC [RFC4033] is the preferred fix for this, but ngl, uptake is so slow right now that you really don't want your setup depending on it 🐢. With cache poisoning, the damage is localized and doesn't last too long 🙌. The catch is that records with a long TTL can stick around even after the attack is over 🕰️.
4.1.13. Publication of Malformed Key Records and/or Signatures 🤒
In this one, the attacker publishes crafted key records or sends mail with deliberately broken signatures 📦. The goal is to confuse the verifier and maybe shut verification down completely 🙃.
This is really more of an implementation bug, like a buffer overflow or missing bounds checking, than a flaw in the signature mechanism itself 🛠️. The best defense is careful implementation plus test suites that really put the verification process through its paces 💪🧪.
4.1.14. Cryptographic Weaknesses in Signature Generation 🧮
The crypto algorithms used to make mail signatures, like the hash algorithm and the digital signature generation and verification operations, can get weaker over time as mathematicians find clever shortcuts 📉. Right now, SHA-1 is under heavy analysis, and it has already gotten a lot faster to make two messages with the same hash value 😳. And this trend is expected to keep going 🏃♀️💨.
One result of a weak hash algorithm is a hash collision attack 💥. This is where the same person creates two different messages with the same hash value, even though only one of them would normally get signed 👯. The trick is that the second message inherits the first message's signature 🧲. With DKIM, a sender could write a "good" message and a "bad" message, and a filter at the signing party's site would sign the good one but not the bad one 🫣. The attacker gets the good message signed, then copies that signature onto the bad message 🎭. It's not common, but it could happen, say, at a site that does content analysis on messages before signing them 🔎.
Right now, the known attacks on SHA-1 make this super hard to pull off 😮💨. But as attacks get better and computing power gets easier to come by, it could become doable 📈.
The message signature system must be designed to support multiple signature and hash algorithms, and the signing domain must be able to say which ones it uses to sign messages 🧩. The choice of algorithms must be published in key records, and not just in the signature itself 📜. That way, an attacker can't make signatures using algorithms weaker than the domain wants to allow 🙅♀️🔒.
Here's the tricky part: signers and verifiers of email don't usually talk to each other directly, so they can't negotiate which algorithm to use 🤷♀️. A signer has no way of knowing which algorithms a verifier supports, or where the verifier even is, thanks to mail forwarding 🌀. So once message signing is widely deployed, algorithm changes will be slow, and legacy algorithms will need to stay supported for a long time 🐌. That means the algorithms used for signatures need to hold up against crypto developments several years down the road 🔮✨.
4.1.15. Display Name Abuse 🎀
Message signatures only cover the address-specification part of an email address 📧. Meanwhile, some MUAs only show the display name part (or some recipients only pay attention to it) 👀. That mismatch opens the door to an attack using a From header field like this:
From: "Dudley DoRight" <whiplash@example.org>Here, the attacker is whiplash@example.org, who can sign the message and still convince some recipients that it's from Dudley DoRight, who's presumably a trusted person 🦹♀️. Add a throwaway domain or email address to the mix, and it gets really hard to hold the attacker accountable for borrowing someone else's display name 😤.
This one has to be handled in the recipient's MUA 📱. One approach is to require that the signer's address specification, and not just the display name, be visible to the recipient 👁️💅.
4.1.16. Compromised System within Originator's Network 🖥️
A lot of the time, MTAs are set up to accept and sign messages that come from inside the originator's network (meaning inside a firewall) 🏰. The growing use of compromised systems to send email is a real problem for that kind of policy 😭. An attacker can use a compromised machine as a proxy and generate signed mail whenever they want 🤖.
There are a few ways to mitigate this 🛡️. Authenticated submission, even inside the network boundaries, can limit which addresses the attacker can get signatures for 🔐. It can also help track down the compromised system that's sending the messages faster 🏃♀️🔍. Content analysis of outbound mail to catch undesirable and malicious content, plus monitoring how much mail users are sending, can also stop arbitrary messages from being signed and sent 🚫📬.
4.1.17. Verification Probe Attack 🛰️
As mentioned above, bad actors can sign messages on behalf of domains they control 😈. And since they might also control the key service (like the authoritative DNS name servers for the _domainkey subdomain), they can watch public key lookups and see where they come from whenever messages get verified 👀🔭.
One version of this, called a "verification probe", goes like this: the attacker sends a message with a DKIM signature to each of many addresses on a mailing list 📬. The messages don't need valid signatures, and each copy typically uses a different selector 🧩. The attacker then monitors the key service requests and figures out which selectors were accessed, and therefore which addressees use DKIM verification 🕵️♀️. That info could be used to target future mailings at recipients who don't use DKIM verification, on the theory that they're more likely to act on what the message says 🎯😬.
4.1.18. Key Publication by Higher-Level Domain 🏢
To let a domain sign for subdomains it administers, DKIM allows the domain in a signature's d= tag to be any higher-level domain than the one in the signature's address (i= or equivalent) 🪜. But there's no mechanism for figuring out whether a subdomain is under common administrative control 🤔. That means a parent can publish keys that are valid for any domain below it in the DNS hierarchy 🌳. For example, mail from example.anytown.ny.us could be signed using keys published by anytown.ny.us, ny.us, or us, as well as the domain itself 🗺️.
Running a domain always involves a trust relationship with higher-level domains 🤝. Those higher-level domains already have ultimate power over their subdomains: they could change the name server delegation for the domain or cut it off entirely 👑. So it's unlikely a higher-level domain would intentionally compromise a subdomain this way 🙏. Still, if higher-level domains send mail on their own behalf, they may want to publish keys at their own level 📮. Higher-level domains must take special care when delegating the keys they publish, so that their subdomains don't get compromised by misuse of those keys 🧯💜.
4.2. Attacks against Message Signing Practices 📋✨
The following is a summary of postulated attacks against signing practices 🌸:
+---------------------------------------------+--------+------------+
| Attack Name | Impact | Likelihood |
+---------------------------------------------+--------+------------+
| Look-alike domain names | High | High |
| Internationalized domain name abuse | High | High |
| Denial-of-service attack against signing | Medium | Medium |
| practices | | |
| Use of multiple From addresses | Low | Medium |
| Abuse of third-party signatures | Medium | High |
| Falsification of Sender Signing Practices | Medium | Medium |
| replies | | |
+---------------------------------------------+--------+------------+4.2.1. Look-Alike Domain Names 🎭
Attackers can try to dodge a domain's signing practices by using a domain name that looks almost identical to it but isn't. Like, examp1e.com instead of example.com 👀. If the message isn't going to be signed, DKIM doesn't require that the domain used actually exists (although other mechanisms might make that a requirement). Some services watch domain registrations to catch potential abuse, but naturally they can't spot the use of domain names that nobody registered 🙃.
A related trick happens when the MUA doesn't show the domain name in an easy-to-read format. If a Chinese domain gets rendered in "punycode" as xn--cjsp26b3obxw7f.com, that unfamiliar look makes it way easier for other domains to get mistaken for the expected one 🌀.
Users who aren't super familiar with how internet names work can mix things up too. For example, people might confuse online.example.com with online-example.com, and guess what, the second one could have been registered by an attacker 😤💅.
4.2.2. Internationalized Domain Name Abuse 🌍
Internationalized domain names are a special case of the look-alike attack we just talked about 🫶. Because lots of Unicode characters look the same, you can create domains (especially ones mixing characters from different scripts) that look totally identical to other domains, possibly super high-value ones. This is covered in detail in [UTR36] 📚, so go read it if you're nerdy like me 🤓.
Watching domain registration records might catch some of these, but there are so many similarities 😭. Just like the look-alike attack above, this technique can also be used to get around sender signing practices of other domains 🦋.
4.2.3. Denial-of-Service Attack against Signing Practices 💥
Just like an attacker can mess with a domain's public key publishing, they can mess with the publishing of Sender Signing Practices (SSP) too 😩. For SSP, sending a huge pile of unsigned mail that pretends to come from the domain can cause a massive load of requests for the SSP record. General DoS attacks against the servers providing SSP records are possible too 🚨. This is a big deal because the default signing practices are "we don't sign everything," which means that if SSP lookups fail, the verifier ends up not paying attention to stricter signing practices 💀.
Same as with DoS defense for key servers, the best move is to run redundant servers, ideally in geographically separate parts of the Internet 🌐. Caching helps a ton again, and since signing practices should rarely change, TTL values can be pretty big 🧁.
4.2.4. Use of Multiple From Addresses 📬
Most recipients will never see this, but [RFC2822] lets the From address hold multiple address specifications 🤯. SSP lookups are based on the From address, so if addresses from multiple domains show up in there, the big question is which signing practices to use 🤔. You could say "use the first address," but then an attacker could stick a throwaway address in front of a high-value domain's address 😤. SSP could also look at all the addresses and pick the most restrictive rule 🔒. This is still an area that needs more study 📖✨.
4.2.5. Abuse of Third-Party Signatures 🎟️
In a bunch of situations, like mailing lists, event invitations, and "send this article to a friend" services, the DKIM signature on a message might not come from the originating address domain 💌. That's why "third-party" signatures (the ones added by the mailing list, invitation service, or news service) often need to be treated as having some validity 🫠. Since this basically lets any domain sign any message, a sending domain can publish sender signing practices saying it doesn't use such services, which means verifiers should look at those signatures with suspicion 🕵️♀️.
However, publishing "no third-party" signing practices effectively blocks lots of existing uses of email 🙃. For the majority of domains that can't adopt these practices, an attacker might have some success signing messages that pretend to come from the domain 😬. So accreditation and reputation services, plus locally-maintained whitelists and blacklists, are going to have to play a big role in evaluating messages signed by third parties 👑.
4.2.6. Falsification of Sender Signing Practices Replies 🎭
Similar to the falsification of key service replies we covered in Section 4.1.12, replies to sender signing practices queries can get falsified too 😱. One sneaky version is weakening the signing practices so unsigned messages allegedly from a domain look less suspicious 🥷. Another attack targets a victim domain that isn't signing messages and tries to make that domain's messages look more suspicious, so the victim can't send mail properly 😭.
Just like with falsified key service replies, DNSSEC is the preferred way to fix this 🔐. Even without DNSSEC, cache poisoning vulnerabilities stay localized 🧹✨.
4.3. Other Attacks 🌪️
This section talks about attacks against other Internet infrastructure that DKIM deployment makes possible 🧚. Here's a quick summary of these postulated attacks:
+--------------------------------------+--------+------------+
| Attack Name | Impact | Likelihood |
+--------------------------------------+--------+------------+
| Packet amplification attacks via DNS | N/A | Medium |
+--------------------------------------+--------+------------+4.3.1. Packet Amplification Attacks via DNS 📈
Recently, there's been a rise in denial-of-service attacks where spoofed UDP DNS requests get sent to openly-accessible domain name servers [US-CERT-DNS] 🚩. To whatever extent the name server's response is bigger than the request, the name server acts as an amplifier for the attack 📣.
DKIM contributes to this indirectly, because it requires publishing fairly large DNS records for distributing public keys 🍓. The names of these records are also well known, since anyone can figure them out by looking at properly-signed messages 👀. This attack doesn't impact DKIM itself, but DKIM isn't the only application using large DNS records, so a DNS-based solution to this problem will likely be required 🛠️💖.
5. Derived Requirements 📝
This section lists requirements for DKIM that weren't explicitly stated in the discussion above 💅. These include:
- The store for key and SSP records must be capable of utilizing multiple geographically-dispersed servers.
- Key and SSP records must be cacheable, either by the verifier requesting them or by other infrastructure.
- The cache time-to-live for key records must be specifiable on a per-record basis.
- The signature algorithm identifier in the message must be one of the ones listed in a key record for the identified domain.
- The algorithm(s) used for message signatures need to be secure against expected cryptographic developments several years in the future.
6. Security Considerations 🔐
This document describes the security threat environment in which DomainKeys Identified Mail (DKIM) is expected to provide some benefit, and it presents a number of attacks relevant to its deployment 🦹♀️💜. Read the whole thing, bestie, it's serious business 😭🚨.
7. Informative References 📚
[Bernstein04] Bernstein, D., "Cache Timing Attacks on AES",
April 2004.
[Boneh03] Boneh, D. and D. Brumley, "Remote Timing Attacks are
Practical", Proc. 12th USENIX Security Symposium,
2003.
[DKIM-BASE] Allman, E., "DomainKeys Identified Mail (DKIM)
Signatures", Work in Progress, August 2006.
[DKIM-SSP] Allman, E., "DKIM Sender Signing Practices", Work in
Progress, August 2006.
[Kocher96] Kocher, P., "Timing Attacks on Implementations of
Diffie-Hellman, RSA, and other Cryptosystems",
Advances in Cryptology, pages 104-113, 1996.
[Kocher99] Kocher, P., Joffe, J., and B. Yun, "Differential Power
Analysis: Leaking Secrets", Crypto '99, pages 388-397,
1999.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version
3", STD 53, RFC 1939, May 1996.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
VERSION 4rev1", RFC 3501, March 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and
S. Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[US-CERT-DNS] US-CERT, "The Continuing Denial of Service Threat
Posed by DNS Recursion".
[UTR36] Davis, M. and M. Suignard, "Unicode Technical Report
#36: Unicode Security Considerations", UTR 36,
July 2005.Appendix A. Acknowledgements 🫶
The author wishes to thank Phillip Hallam-Baker, Eliot Lear, Tony Finch, Dave Crocker, Barry Leiba, Arvel Hathcock, Eric Allman, Jon Callas, Stephen Farrell, Doug Otis, Frank Ellermann, Eric Rescorla, Paul Hoffman, Hector Santos, and numerous others on the ietf-dkim mailing list for valuable suggestions and constructive criticism of earlier versions of this document 🌸💖. Iconic behaviour from all of them 👑.
Author's Address 📮
Jim Fenton
Cisco Systems, Inc.
MS SJ-9/2
170 W. Tasman Drive
San Jose, CA 95134-1706
USA
Phone: +1 408 526 5914
EMail: fenton@cisco.comFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 💖
okay so the IETF is not picking a side on whether any Intellectual Property Rights (IPR) or other rights someone claims over the tech in this doc are valid, or how far they reach 🙈 it also doesn't say it went looking for those rights itself ✨ if you want the rules for rights in RFC docs, check out BCP 78 and BCP 79 💅
copies of IPR disclosures sent to the IETF Secretariat are a whole thing too 🎀 so are any promises of licenses, plus results from anyone trying to get a general license or permission to use those proprietary rights as an implementer or user of this spec. all of that lives in the IETF online IPR repository at http://www.ietf.org/ipr 🌸
and if you think you've got a copyright, patent, patent application, or other proprietary right that might cover tech you'd need to build this standard, the IETF wants to hear about it 👑 send it to ietf-ipr@ietf.org ⭐
Acknowledgement 🫶
the RFC Editor function gets its funding from the IETF Administrative Support Activity (IASA) 💜
📦 where this page comes from
- ietf: rfc4686 2006-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms