From my comments on the ietf-mailsig mailing list.
Below the fold.
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 starting a major new effort without
having some level of comfort that it will actually work.
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.
They're doing textbook RSA signing? My goodness gracious.
(Why not DSA? If we're stuck with RSA, they definitely need some sort of padding scheme. Maybe PSS?)
I think they're not really using textbook RSA. They probably just don't think about it. After all, you just call RSA_sign(), right?
It's RSA; perhaps needs to be described better. RSA has the advantage over DSA that it places more of the cost of signing/verifying on the signer. While we don't view this as a "hashcash" scheme or anything, this is a nice property in this application. We want to minimize the time required to process intentionally bogus signatures.
RSA only has that property if the public exponent e is small. If someone is trying to deny service with bogus signatures, why won't he publish a key with a large e?
Indeed. And generating bogus signatures is trivial, generate a 128-byte random value.
re 5.9.4, 'Wait, isn't this exactly the kind of attack pharmers mount?'
a quick google for "pharming" seems to indicate that it's used to refer to an attacker persuading a registrar to transfer a domain name, e.g. http://www.greenarmor.com/pharming.shtml . Is that what you mean, or do you have another "pharming" in mind? That seems to be an entirely social-engineering-based attack, which doesn't jibe with 5.9.4's discussion of costly, extensive, and prolonged attacks on DNS infrastructure.
update: found it. a comment at http://www.csoonline.com/talkback/071905.html notes another, entirely separate, meaning for 'pharming'.
Anyway, I'd recommend clarifying that comment, since the term clearly has multiple conflicting meanings. (damn neologists!)