reputation of a competitor, perhaps by sending unsolicited bulk email
on behalf of that competitor. It is for this reason that reputation
systems must be based on an identity that is, in practice, fairly
reliable.
3.2.4. Reflection Attacks
A commonly-used tactic by some bad actors is the indirect
transmission of messages by intentionally mis-addressing the message
and causing it to be "bounced", or sent to the return address (RFC
2821 envelope-from address) on the message. In this case, the
specific identity asserted in the email is that of the actual target
of the message, to whom the message is "returned".
DKIM does not, in general, attempt to validate the RFC2821.mailfrom
return address on messages, either directly (noting that the mailfrom
address is an element of the SMTP protocol, and not the message
content on which DKIM operates), or via the optional Return-Path
header field. Furthermore, as is noted in Section 4.4 of RFC 2821
[RFC2821], it is common and useful practice for a message’s return
path not to correspond to the origin address. For these reasons,
DKIM is not effective against reflection attacks.
4. Attacks on Message Signing
Bad actors can be expected to exploit all of the limitations of
message authentication systems. They are also likely to be motivated
to degrade the usefulness of message authentication systems in order
to hinder their deployment. Both the signature mechanism itself and
declarations made regarding use of message signatures (referred to
here as Sender Signing Practices or SSP) can be expected to be the
target of attacks.
4.1. Attacks against Message Signatures
The following is a 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 technologies such as DKIM are vulnerable to theft of
the private keys used to sign messages. This includes "out-of-band"
means for this theft, such as burglary, bribery, extortion, and the
like, as well as electronic means for such theft, such as a
compromise of network and host security around the place where a
private key is stored.
Keys that are valid for all addresses in a domain typically reside in
MTAs that should be located in well-protected sites, such as data
centers. Various means should be employed for minimizing access to
private keys, such as non-existence of commands for displaying their
value, although ultimately memory dumps and the like will probably
contain the keys. Due to the unattended nature of MTAs, some
countermeasures, such as the use of a pass phrase to "unlock" a key,
are not practical to use. Other mechanisms, such as the use of
dedicated hardware devices that contain the private key and perform
the cryptographic signature operation, would be very effective in
denying export of the private key to those without physical access to
the device. Such devices would almost certainly make the theft of
the key visible, so that appropriate action (revocation of the
corresponding public key) can be taken should that happen.
4.1.2. Theft of Delegated Private Key
There are several circumstances where a domain owner will want to
delegate the ability to sign messages for the domain to an individual
user or a third party associated with an outsourced activity such as
a corporate benefits administrator or a marketing campaign. Since
these keys may exist on less well-protected devices than the domain’s
own MTAs, they will in many cases be more susceptible to compromise.
In order to mitigate this exposure, keys used to sign such messages
can be restricted by the domain owner to be valid for signing
messages only on behalf of specific addresses in the domain. This
maintains protection for the majority of addresses in the domain.
A related threat is the exploitation of weaknesses in the delegation
process itself. This threat can be mitigated through the use of
customary precautions against the theft of private keys and the
falsification of public keys in transit. For example, the exposure
to theft can be minimized if the delegate generates the keypair to be
used, and sends the public key to the domain owner. The exposure to
falsification (substitution of a different public key) can be reduced
if this 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 variety of
side channel attacks. The most well-known of these are timing
channels [Kocher96], power analysis [Kocher99], and cache timing
analysis [Bernstein04]. Most of these attacks require 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.
However, remote timing analysis (at least on local area networks) is
known to be feasible [Boneh03], particularly in server-type platforms
where the attacker can inject traffic that will immediately be
subject to the cryptographic operation in question. With enough
samples, these techniques can be used to extract private keys even in
the face of modest amounts of noise in the timing measurements.
The three commonly proposed countermeasures against timing analysis
are:
1. Make the operation run in constant time. This turns out in
practice to be rather difficult.
2. Make the time independent of the input data. This can be
difficult, but see [Boneh03] for more details.
3. Use blinding. This is generally considered the best current
practice countermeasure, and while not proved generally secure is
a countermeasure against known timing attacks. It adds about
2-10% to the cost of the operation and is implemented in many
common cryptographic libraries. Unfortunately, Digital Signature
Algorithm (DSA) and Elliptic Curve DSA (ECDSA) do not 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
Chosen message replay refers to the scenario where the attacker
creates a message and obtains a signature for it by sending it
through an MTA authorized by the originating domain to
himself/herself or an accomplice. They then "replay" the signed
message by sending it, using different envelope addresses, to a
(typically large) number of other recipients.
Due to the requirement to get an attacker-generated message signed,
chosen message replay would most commonly be experienced by consumer
ISPs or others offering email accounts to clients, particularly where
there is little or no accountability to the account holder (the
attacker in this case). One approach to solving this problem is for
the domain to only sign email for clients that have passed a vetting
process to provide traceability to the message originator in the
event of abuse. At present, the low cost of email accounts (zero)
does not make it practical for any vetting to occur. It remains to
be seen whether this will be the model with signed mail as well, or
whether a higher level of trust will be required to obtain an email
signature.
A variation on this attack involves the attacker sending a message
with the intent of obtaining a signed reply containing their original
message. The reply might come from an innocent user or might be an
automatic response such as a "user unknown" bounce message. In some
cases, this signed reply message might accomplish the attacker’s
objectives if replayed. This variation on chosen message replay can
be mitigated by limiting the extent to which the original content is
quoted in automatic replies, and by the use of complementary
mechanisms such as egress content filtering.
Revocation of the signature or the associated key is a potential
countermeasure. However, the rapid pace at which the message might
be replayed (especially with an army of "zombie" computers), compared
with the time required to detect the attack and implement the
revocation, is likely to be problematic. A related problem is the
likelihood that domains will use a small number of signing keys for a
large number of customers, which is beneficial from a caching
standpoint but is likely to result in a great deal of collateral
damage (in the form of signature verification failures) should a key
be revoked suddenly.
Signature revocation addresses the collateral damage problem at the
expense of significant scaling requirements. At the extreme,
verifiers could be required to check for revocation of each signature
verified, which would result in very significant transaction rates.
An alternative, "revocation identifiers", has been proposed, which
would permit revocation on an intermediate level of granularity,
perhaps on a per-account basis. Messages containing these
identifiers would result in a query to a revocation database, which
might be represented in DNS.
Further study is needed to determine if the benefits from revocation
(given the potential speed of a replay attack) outweigh the
transactional cost of querying a revocation database.
4.1.5. Signed Message Replay
Signed message replay refers to the retransmission of already-signed
messages to additional recipients beyond those intended by the author
or the original poster of the message. The attacker arranges to
receive a message from the victim, and then retransmits it intact but
with different envelope addresses. This might be done, for example,
to make it look like a legitimate sender of messages is sending a
large amount of spam. When reputation services are deployed, this
could damage the author’s reputation or that of the author’s domain.
A larger number of domains are potential victims of signed message
replay than chosen message replay because the former does not require
the ability for the attacker to send messages from the victim domain.
However, the capabilities of the attacker are lower. Unless coupled
with another attack such as body length limit abuse, it isn’t
possible for the attacker to use this, for example, for advertising.
Many mailing lists, especially those that do not modify the content
of the message and signed header fields and hence do not invalidate
the signature, engage in a form of signed message replay. The use of
body length limits and other mechanisms to enhance the survivability
of messages effectively enhances the ability to do so. The only
things that distinguish this case from undesirable forms of signed
message replay is the intent of the replayer, which cannot be
determined by the network.
4.1.6. Denial-of-Service Attack against Verifier
While it takes some computing resources to sign and verify a
signature, it takes negligible computing resources to generate an
invalid signature. An attacker could therefore construct a "make
work" attack against a verifier, by sending a large number of
incorrectly-signed messages to a given verifier, perhaps with
multiple signatures each. The motivation might be to make it too
expensive to verify messages.
While this attack is feasible, it can be greatly mitigated by the
manner in which the verifier operates. For example, it might decide
to accept only a certain number of signatures per message, limit the
maximum key size it will accept (to prevent outrageously large
signatures from causing unneeded work), and verify signatures in a
particular order. The verifier could also maintain state
representing the current signature verification failure rate and
adopt a defensive posture when attacks may be under way.
4.1.7. Denial-of-Service Attack against Key Service
An attacker might also attempt to degrade the availability of an
originator’s key service, in order to cause that originator’s
messages to be unverifiable. One way to do this might be to quickly
send a large number of messages with signatures that reference a
particular key, thereby creating a heavy load on the key server.
Other types of DoS attacks on the key server or the network
infrastructure serving it are also possible.
The best defense against this attack is to provide redundant key
servers, preferably on geographically-separate parts of the Internet.
Caching also helps a great deal, by decreasing the load on
authoritative key servers when there are many simultaneous key
requests. The use of a key service protocol that minimizes the
transactional cost of key lookups is also beneficial. It is noted
that the Domain Name System has all these characteristics.
4.1.8. Canonicalization Abuse
Canonicalization algorithms represent a tradeoff between the survival
of the validity of a message signature and the desire not to allow
the message to be altered inappropriately. In the past,
canonicalization algorithms have been proposed that would have
permitted attackers, in some cases, to alter the meaning of a
message.
Message signatures that support multiple canonicalization algorithms
give the signer the ability to decide the relative importance of
signature survivability and immutability of the signed content. If
an unexpected vulnerability appears in a canonicalization algorithm
in general use, new algorithms can be deployed, although it will be a
slow process because the signer can never be sure which algorithm(s)
the verifier supports. For this reason, canonicalization algorithms,
like cryptographic algorithms, should undergo a wide and careful
review process.
4.1.9. Body Length Limit Abuse
A body length limit is an optional indication from the signer of how
much content has been signed. The verifier can either ignore the
limit, verify the specified portion of the message, or truncate the
message to the specified portion and verify it. The motivation for
this feature is the behavior of many mailing lists that add a
trailer, perhaps identifying the list, at the end of messages.
When body length limits are used, there is the potential for an
attacker to add content to the message. It has been shown that this
content, although at the end, can cover desirable content, especially
in the case of HTML messages.
If the body length isn’t specified, or if the verifier decides to
ignore the limit, body length limits are moot. If the verifier or
recipient truncates the message at the signed content, there is no
opportunity for the attacker to add anything.
If the verifier observes body length limits when present, there is
the potential that an attacker can make undesired content visible to
the recipient. The size of the appended content makes little
difference, because it can simply be a URL reference pointing to the
actual content. Receiving MUAs can mitigate this threat by, at a
minimum, identifying the unsigned content in the message.
4.1.10. Use of Revoked Key
The benefits obtained by caching of key records opens the possibility
that keys that have been revoked may be used for some period of time
after their revocation. The best examples of this occur when a
holder of a key delegated by the domain administrator must be
unexpectedly deauthorized from sending mail on behalf of one or more
addresses in the domain.
The caching of key records is normally short-lived, on the order of
hours to days. In many cases, this threat can be mitigated simply by
setting a short time-to-live (TTL) for keys not under the domain
administrator’s direct control (assuming, of course, that control of
the TTL value may be specified for each record, as it can with DNS).
In some cases, such as the recovery following a stolen private key
belonging to one of the domain’s MTAs, the possibility of theft and
the effort required to revoke the key authorization must be
considered when choosing a TTL. The chosen TTL must be long enough
to mitigate denial-of-service attacks and provide reasonable
transaction efficiency, and no longer.
4.1.11. Compromise of Key Server
Rather than by attempting to obtain a private key, an attacker might
instead focus efforts on the server used to publish public keys for a
domain. As in the key theft case, the motive might be to allow the
attacker to sign messages on behalf of the domain. This attack
provides the attacker with the additional capability to remove
legitimate keys from publication, thereby denying the domain the
ability for the signatures on its mail to verify correctly.
In order to limit the ability to sign a message to entities
authorized by the owner of a signing domain, a relationship must be
established between the signing address and the location from which a
public key is obtained to verify the message. DKIM does this by
publishing either the public key or a reference to it within the DNS
hierarchy of the signing domain. The verifier derives the location
from which to retrieve the public key from the signing address or
domain. The security of the verification process is therefore
dependent on the security of the DNS hierarchy for the signing
domain.
An attacker might successfully compromise the host that is the
primary key server for the signing domain, such as the domain’s DNS
master server. Another approach might be to compromise a higher-
level DNS server and change the delegation of name servers for the
signing domain to others under the control of the attacker.
This attack can be mitigated somewhat by independent monitoring to
audit the key service. Such auditing of the key service should occur
by means of zone transfers rather than queries to the zone’s primary
server, so that the addition of records to the zone can be detected.
4.1.12. Falsification of Key Service Replies
Replies from the key service may also be spoofed by a suitably
positioned attacker. For DNS, one such way to do this is "cache
poisoning", in which the attacker provides unnecessary (and
incorrect) additional information in DNS replies, which is cached.
DNSSEC [RFC4033] is the preferred means of mitigating this threat,
but the current uptake rate for DNSSEC is slow enough that one would
not like to create a dependency on its deployment. In the case of a
cache poisoning attack, the vulnerabilities created by this attack
are both localized and of limited duration, although records with
relatively long TTL may persist beyond the attack itself.
4.1.13. Publication of Malformed Key Records and/or Signatures
In this attack, the attacker publishes suitably crafted key records
or sends mail with intentionally malformed signatures, in an attempt
to confuse the verifier and perhaps disable verification altogether.
This attack is really a characteristic of an implementation
vulnerability, a buffer overflow or lack of bounds checking, for
example, rather than a vulnerability of the signature mechanism
itself. This threat is best mitigated by careful implementation and
creation of test suites that challenge the verification process.
4.1.14. Cryptographic Weaknesses in Signature Generation
The cryptographic algorithms used to generate mail signatures,
specifically the hash algorithm and digital signature generation and
verification operations, may over time be subject to mathematical
techniques that degrade their security. At this writing, the SHA-1
hash algorithm is the subject of extensive mathematical analysis that
has considerably lowered the time required to create two messages
with the same hash value. This trend can be expected to continue.
One consequence of a weakness in the hash algorithm is a hash
collision attack. Hash collision attacks in message signing systems
involve the same person creating two different messages that have the
same hash value, where only one of the two messages would normally be
signed. The attack is based on the second message inheriting the
signature of the first. For DKIM, this means that a sender might
create a "good" message and a "bad" message, where some filter at the
signing party’s site would sign the good message but not the bad
message. The attacker gets the good message signed, and then
incorporates that signature in the bad message. This scenario is not
common, but could happen, for example, at a site that does content
analysis on messages before signing them.
Current known attacks against SHA-1 make this attack extremely
difficult to mount, but as attacks improve and computing power
becomes more readily available, such an attack could become
achievable.
The message signature system must be designed to support multiple
signature and hash algorithms, and the signing domain must be able to
specify which algorithms it uses to sign messages. The choice of
algorithms must be published in key records, and not only in the
signature itself, to ensure that an attacker is not able to create
signatures using algorithms weaker than the domain wishes to permit.
Because the signer and verifier of email do not, in general,
communicate directly, negotiation of the algorithms used for signing
cannot occur. In other words, a signer has no way of knowing which
algorithm(s) a verifier supports or (due to mail forwarding) where
the verifier is. For this reason, it is expected that once message
signing is widely deployed, algorithm change will occur slowly, and
legacy algorithms will need to be supported for a considerable
period. Algorithms used for message signatures therefore need to be
secure against expected cryptographic developments several years into
the future.
4.1.15. Display Name Abuse
Message signatures only relate to the address-specification portion
of an email address, while some MUAs only display (or some recipients