1.0 Background
DomainKeys Identified Mail (DKIM) is basically an anti-forgery
measure. The idea is that MTAs serving a given domain will
digitally sign messages they forward. Thus, recipients will
be able to detect forgery by absence of a valid signature.
Signing keys are made available via DNS.
2.0 General Comments
2.1 Lack of Complete Motivation
The context in which DKIM (and other similar proposals) is introduced
is that of spam/phishing prevention. Much (most?) spam is forged
and therefore it's often believed that stopping forgery is a
first step to stopping spam/phishing. This is a contentious
argument with points on both sides, but this document doesn't really
address it at all. It just hand-waves in that direction in the
introduction:
The ultimate goal of this framework is to prove
and protect message sender identity and the integrity of the messages
they convey while retaining the functionality of Internet email as it
is known today. Proof and protection of email identity, including
repudiation and non-repudiation, may assist in the global control of
"spam" and "phishing".
In my opinion, a substantial new piece of work like this needs
to start with a threat analysis of the problem and an attempt
to determine whether the proposed solution is likely to actually
help. I don't see any of this here. I appreciate that the authors
don't want to get drawn into an extended debate, but I'm also
quite uncomfortable with IETF engaging in major new effort without
having some level of comfort that it will actually succeed.
2.2 Duplication of Existing Mechanisms
DKIM really consists of two loosely coupled protocols.
(1) A message signing protocol with characteristics somewhat
reminiscent of PEM.
(2) A key retrieval protocol to retrieve the keys used
for (1), as well as to deliver policy about what
messages are expected to be signed.
There's no reason why these two need to be coupled at all.
Indeed, it would make a lot of sense to couple a generic
message signature protocol to the key retrieval mechanism
described here.
2.2.1 Message Signing Protocol
At the time of this writing, the IETF has RFCs documenting no
less than four protocols for cryptographically signing e-mail
messages: PEM (RFC1421-1424), MOSS (RFC 1848), S/MIME (RFC 3850-3853),
and OpenPGP (RFC 2440, RFC 3156). All of these were designed to
solve the same basic problem: cryptographically protecting
a message so that it could survive transport via as many
MTAs as possible and still be readable (and verifiable) on
the other end.
DKIM introduces yet another such protocol, one which is conspicuously
less elegant than the currently dominant Security/Multiparts
approach (RFC 1847). What motivation for this choice there is
is in S 1.1:
the message signature is written to the message header fields so
that neither human recipients nor existing MUA software are
confused by signature-related content appearing in the message
body
As it happens, this was the design that PEM used but was discarded for
S/MIME. As I recall, part of the motivation was the concern at the
time was that the headers would be mangled or removed by MTAs.
I'm not enough of a mail expert to have an informed opinion
on which packaging is superior from the perspective of compatibility,
however it seems to me that the compatibility requirements for
{S/MIME,OpenPGP} and this application are essentially similar.
If the approach described in DKIM is superior, then shouldn't
we be retargeting S/MIME and OpenPGP to use it? And if not, then
shouldn't DKIM be using S/MIME or OpenPGP?
2.3 General Complexity
The interaction of this design with all the mail headers seems
extremely complex and easy to screw up. Maybe that's necessary
and I don't have an easy way to simplify it, but it's worth
noting.
3.0 Detailed Comments
Below, quotes are set off by -----
S 1.1
------
The approach taken by DKIM differs from previous approaches to
message signing (e.g. S/MIME, OpenPGP) in that:
o the message signature is written to the message header fields so
that neither human recipients nor existing MUA software are
confused by signature-related content appearing in the message
body
o there is no dependency on public and private key pairs being
issued by well-known, trusted certificate authorities
o there is no dependency on the deployment of any new Internet
protocols or services for public key distribution or revocation.
-----
The first point does not apply to PEM (RFC 1421). The second and
third points are sort of misleading since OpenPGP and S/MIME
can work perfectly well with e.g., self-signed certificates.
And with the same level of effort required to distribute DKIM
keys you could build key distribution systems for S/MIME and
OpenPGP with similar levels of assurance.
-----
o does not require the use of a trusted third party (such as a
certificate authority or other entity) which might impose
significant costs or introduce delays to deployment
o can be deployed incrementally.
-----
I'm not convinced that this *can* be deployed incrementally.
The key here is to focus on the amount of information provided
by a message being unsigned. If most of the internet is sending
unsigned messages, then the negative weight you can assign to
someone not being signed is necessarily very small and so it's
not very useful for spam triage. This is exactly the kind of
question which needs to be addressed in a security analysis of this
class of system.
S 1.4:
-----
DKIM differs from traditional hierarchical public-key systems in that
no key signing infrastructure is required; the verifier requests the
public key from the claimed signer directly.
-----
I wouldn't characterize a DNS query to a server quite possibly not
controlled by the same person as the MTA as "directly". For instance,
I operate my own MTA but name service is provided by my ISP.
S 3.3.1:
------
The rsa-sha1 Signing Algorithm computes a SHA-1 hash of the message
header field and body as described in section XINDX below. That hash
is then encrypted by the signer using the RSA algorithm and the
signer's private key. The hash MUST NOT be truncated or converted
into any form other than the native binary form before being signed.
More formally, the algorithm for the signature using rsa-sha1 is:
RSA(SHA1(canon_message, DKIM-SIG), key)
------
It would be great if people would stop using the word "encrypted" in
the context of RSA signatures. Yes, it's true that you're taking
the plaintext (well hash) and doing M^d and that that's the same
operation as the RSA encryption operation, but it's not encrption
in any real sense because everyone can decrypt it. Moroever, it
confuses the issue because DSA signing is totally different.
Also, "RSA" isn't a single function because of the padding issue.
You need to specify PKCS#1 something or other. There's a normative
ref to RFC 3447 but nothing in the text.
Also, SHA-1 doesn't take two arguments. I assume you mean concatenation,
in which case I recommend:
RSA(SHA1(canon_message || DKIM-SIG), key)
S 3.3.3:
-----
o Larger keys impose higher CPU costs to verify and sign email
-----
The CPU cost to verify even fairly large RSA signatures is extremely
small.
S 3.4:
------
algorithms. To avoid this attack, signers should be wary of using
this tag, and verifiers might wish to ignore the tag or remove
text that appears after the specified content length.
------
If verifiers ignore the tag, the signature will fail to verify,
right? That doesn't seem like what we want.
S 3.5:
------
INFORMATIVE RATIONALE: The authors understand that SHA-1 has
been theoretically compromised. However, viable attacks
require the attacker to choose both sets of input text; given a
preexisting input (a "preimaging" attack), it is still hard to
determine another input that produces an SHA-1 collision, and
the chance that such input would be of value to an attacker is
minimal. Also, there is broad library for SHA-1, whereas
alternatives such as SHA-256 are just emerging. Finally, DKIM
is not intended to have legal- or military-grade requirements.
There is nothing inherent in using SHA-1 here other than
implementer convenience. See
<http://www3.ietf.org/proceedings/05mar/slides/saag-3.pdf> for
a discussion of the security issues.
-------
I'm not sure that I agree with this analysis. If the model for the
MTA is that it's going to blindly sign any message from someone
who is authorized, then I agree with you, but that's not the
only model. Consider an MTA which does some outgoing spam filtering
and only signs messages it thinks aren't spam--this is to contain
botnet compromise.
In this case, the attacker prepares two colliding messages, one
spam and one innocuous. He gets the MTA to sign the innocuous one
and then substitutes on output. Note that this is possible because
of the extension property of SHA-1 and the choice to put the message
contents first in the SHA-1.
S 4:
-----
Further confusion could occur with multiple signatures added at the
same logical "depth". For example, a signer could choose to sign
using different signing or canonicalization algorithms. However,
even this is problematic because some of those signatures will
inevitably have to sign some of the others (and at very minimum must
be presented to the verification algorithm in the same order as
presented to the signature algorithm).
-----
Note that this is a result of the particular signature formatting
choices used by the designers. S/MIME handles parallel signatures
with no problem.
S 5.2.2:
-----
INFORMATIVE ADMONITION: Despite the fact that [RFC2822] permits
header field blocks to be reordered (with the exception of
Received header fields), reordering of signed replicated header
fields by intermediate MTAs will cause DKIM signatures to be
broken; such anti-social behavior should be avoided.
-----
How likely is this to happen? If current MTAs behave this way,
then that rather weakens the claim that DKIM is incrementally
deployable.
S 6.4:
-----
o Based on the algorithm indicated in the "a=" tag,
* Compute the message hash from the canonical copy as described
in section XINDX. Note that this requires presenting the
"nowsp" canonicalized DKIM-Signature header field to the hash
algorithm after the body of the message, and with the "b="
value treated as the empty string.
* Decrypt the signature using the signer's public key.
o Compare the decrypted signature to the message hash.
INFORMATIVE IMPLEMENTER'S NOTE: Implementations might wish to
initiate the public-key query in parallel with calculating the
hash as the public key is not needed until the final decryption is
calculated.
-----
Again, please avoid the terminology of digital signature verification
as decryption.
S 9.3:
-----
Since the key servers are distributed (potentially separate for each
domain), the number of servers that would need to be attacked to
defeat this mechanism on an Internet-wide basis is very large.
Nevertheless, key servers for individual domains could be attacked,
impeding the verification of messages from that domain. This is not
significantly different from the ability of an attacker to deny
service to the mail exchangers for a given domain, although it
affects outgoing, not incoming, mail.
-----
I think this analysis misses something important: DKIM depends on
wide deployment of signing infrastructure in order to make
a message being not signed meaningful. If popular senders
are regularly unverifiable, this strongly reduces recipients
incentive to make decisions based on DKIM settings.
S 9.4:
------
To systematically thwart the intent of DKIM, an attacker must conduct
a very costly and very extensive attack on many parts of the DNS over
an extended period. No one knows for sure how attackers will
respond, however the cost/benefit of conducting prolonged DNS attacks
of this nature is expected to be uneconomical.
-----
Wait, isn't this exactly the kind of attack pharmers mount?
S 9.5:
Wouldn't one defense against this be to match the To: lines?