Weaknesses in the WikiLeaks system....of course, this is just Wikipedia info
Weaknesses[edit]
The RFC itself identifies a number of potential attack vectors.
[29]
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 [
clarification needed]. 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[edit]
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 they 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.
[30]
Content modification[edit]
DKIM currently features two
canonicalization algorithms, simple and relaxed, neither of which is
MIME-aware.
[31] 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,
[32] 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.
[33]
Annotations by mailing lists[edit]
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.
[34]
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.
[35] 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[edit]
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
RFC 6376 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
RFC 6376 also states that signers must use keys of at least 1024 bits for long-lived keys, though long-livingness is not specified there.
[36]