On 30 Jul 2005, at 9:56 PM, EKR wrote:
Here's a detailed response to many of the issues. I'm editing responses
from various of my co-authors along with my own.
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.
Absence of a valid signature does not imply forgery, but presence of a
valid signature is strong evidence to the contrary.
Furthermore, one of the values of DKIM is that the presence of a
signature might have positive or negative value. For example, as a
receiver, I might consider a DKIM signature from ebay.com to be a good
thing and deliver the message to the recipient with no further
checking. I might consider a DKIM signature from 3bay.com to be reason
to delete the message, add in additional metadata (like a Spam
Assassin-compatible header), or something else. All of these, however,
are beyond the scope of this document, if not the whole (proposed) DKIM
working group.
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".
We put spam and phishing last, and identity protection first, for the
exact reasons that you stated at the first MASS BOF: these are social
problems, and do not lend themselves to a purely technical solution.
We consider DKIM to be an authentication foundation for accreditation,
reputation and other authorization services. Presently, there is not a
good, reliable mechanism to build these on other than IP address. DKIM
uses digital signatures to provide that foundation.
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.
Noted. We know we need to provide a threat analysis. We're working on
it and there should be a draft of one by the BOF on Thursday.
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.
As others have said, DKIM differs from PEM, S/MIME, and OpenPGP in that
it puts the signatures in the headers. It's not like them at all.
It does provide a protocol to pull the signing keys out of the network.
It defines doing this with DNS, but it's not limited to that.
Extensions to DKIM to allow XKMS retrieval, an IIM-like KRS, or any
variety of other protocols might be reasonable. They're beyond what
we're describing here.
We also have as part of the whole protocol some other information that
helps to evaluate the signatures. We have scoping so that you can
delegate some part of your signing to a partner or outsourcer. Jim's
classic example is that you can set up parameters for
"benefits(_at_)cisco(_dot_)com" and allow your insurance company to send out
benefits mail on your behalf. We also have ways that a signer can say
things like, "I only sign with RSA 2048 bit keys and SHA-512." These
are mechanisms that are very, very important for a protocol like DKIM
that are not addressed at all in S/MIME or OpenPGP.
I'm not sure what to say more about decoupling. You're certainly right
that we could do it. The present structure owes a lot to the way that
we merged the DK and IIM documents. We could make another revision that
would separate things into two documents, but would that actually add
anything? You'd still have to read them both before you understood the
system, and one could argue that that makes it less understandable.
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?
The main thing that DKIM is designed to do is to have the sending
administrative domain sign a message for the benefit of the receiving
administrative domain. It's not the same thing as S/MIME or OpenPGP,
which are *user*-level signatures.
If this message were signed, it would be a statement by callas.org
saying that the message was properly sent according to its own
policies. When I first spoke to the Yahoo guys, they said that the goal
of (then) DomainKeys was so that Yahoo as an ISP can know that a
message that purports to come from eBay really did, even if it bounces
off of the recipient's alumni association. I think that's a good,
concise description of what problem we're trying to solve.
Last October, I wrote a note to this list saying why I think that we
need a new protocol. It is at
<http://www.imc.org/ietf-mailsig/mail-archive/msg00232.html>. I wrote
another note recently that touches upon the same basic issues, of why
we're doing what we're doing. That is at
<http://www.imc.org/ietf-mailsig/mail-archive/msg01549.html>. I also
recently wrote this article
<http://www.pgp.com/library/ctocorner/dkim.html> that I believe also
touches upon your concerns.
I mention in my other notes another advantage that I'll call out here
again. That is that we do not *require* special MUA support. An MUA
that speaks DKIM can add value, but it's not needed. When we spoke to
senders who want to use DKIM for authenticating mail to their often
naive customer base, it's important to them that DKIM signature not
alter the appearance of an email. Additionally, I can tell you from my
experience that it is very difficult to create a complex MIME message
that displays correctly if I don't know a priori what your MUA is. By
"very difficult" I mean that we've not found a profile of MIME features
that scales well at all.
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.
Okay. We want DKIM to be expressive. We also want it to be simple.
There are also parts of DKIM that are under debate even among those of
us who produced it (the "l=" option being an obvious example).
However, there are now five implementations of it, so it can't be that
hard to implement. (I am smiling as I say that.) Part of any perceived
complexity might also come from our desire to be upwards-compatible
with DomainKeys; ironically, we already have legacy compatibility to
deal with.
We want the creation and verification of signatures to be as mechanical
as possible, and the interpretation of the signature to be handled by
other mechanisms.
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.
One of the goals of DKIM is to be key-centric rather than certificate
centric, while allowing that there is value to perhaps layering
certificates on top of it.
DKIM is intentionally not a protocol for authorizing a financial
transaction. It is a protocol for protecting the transport of a
message. That message might contain in it S/MIME, OpenPGP, XMLDIGSIG,
etc. content that handles the transaction, and that would be backed by
a certificate system, quite likely.
-----
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.
We agree we're not being as clear as we should be. Let me try to
explain what we mean.
Go back to the Yahoo basic explanation. If no one in the world but
Yahoo and eBay implemented DKIM, they'd get value out of it. Adoption
across the entire Internet isn't required. If the Nigerian Phishers
Association then adopts DKIM, it provides further benefit to Yahoo,
because they know that NPA messages are coming from the NPA, and it can
handle them appropriately.
On the flip side, incremental means that a DKIM-signed message has no
adverse affect on the recipient. For example, Gmail is presently
signing all messages with DomainKeys, and unless you look at the
headers, you wouldn't have noticed. (Now on the other hand, I'm amused
that the archives of this list does show the DKIM headers.)
Another way to look at it is that if you authenticate with DKIM, then
we can use reputation to make a decision about the email. If there's no
signature, or indeterminate reputation, we do scanning by content, just
as we'd do today.
Does this help explain what we mean?
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.
Yes, but you're allowed to put entries into your DNS, aren't you? Maybe
we're being glib, but if I outsource my DNS, I consider it to be under
my direct control, even if I'm not personally changing the configs and
hupping the server process.
We are trying to achieve similar level of security for outgoing mail as
for incoming. If you trust your ISP enough not to divert your incoming
mail with bogus MX records, why wouldn't you trust them to advertise
public keys for verifying your mail?
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)
Noted. We'll fix these.
Let me give my personal apology also, because it's also a peeve of mine
that specs about signing should say "sign" and "verify" rather than
"encrypt" and "decrypt." I should have caught this before it went out.
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.
Maybe. The CPU cost to verify signatures is small if it's a fast
processor that spends a lot of its time idle.
I commonly read my mail from two machines. One is a 1.5GHz PPC, the
other is a 40MHz x386. On the latter machine, the difference between a
"small" signature and a "large" one is measured in seconds.
In the other dimension, if you have a fast CPU that is very busy, it
might also be a concern. Take a server that processes 12 million
messages per day. On that machine, a difference of a millisecond per
signature ends up being over three CPU-hours per day. That may or may
not make a difference.
It's a true statement that larger keys impose higher CPU costs. What
would you like us to say?
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.
It will only fail to verify if something was added to the body. What do
we want? Do we want the verification to succeed if the body was
modified? If we do, we can address this by designing an appropriate
canonicalization algorithm.
Message appending is only allowed if both the sender and recipient
allow it. This is the l= option. As you can no doubt tell from the
wording around it, it's something that we know is valuable, but with
risk. We think that there are good ways to mitigate the risk of abuse
of l=. Some of these are protocol, some are implementation. Note that
the protocol helpfully suggests that an implementation might truncate a
message that uses l= and has been appended to. Also, an implementation
can make the decision to use l= on a message-by-message basis.
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.
I'm not sure I understand what you're saying. If we assume a thorough
compromise of SHA-1, one in which it is "easy" to get a pre-image
collision, then yeah, the attacker can take a signed message and make a
colliding message that passes signature verification. That's why a
complete break of a hash algorithm would be bad.
Would it make you feel better if we just stopped talking about SHA-1
and went right now to SHA-256? We have tags that allow the sender to
specify the hash algorithm used in the message. We also have ways for
the signing domain to specify which algorithms may be used with a given
key. We believe this takes care of any downgrade problems that might
exist with weak hash algorithms.
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.
Noted. There is additional work to be done with multiple signatures.
It may not even be necessary to characterize the ordering of the
signatures, so this may not be a 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.
It's not very likely. It's only a problem if the signer signs a
replicable header and the spec discourages this.
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.
Noted. Again, I'm sorry I didn't catch this.
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.
I think that you may not have seen that a sender can announce to the
world that they sign all messages and please reject any unsigned ones.
This policy statement means that an unsigned message from such a domain
is meaningful, and in a negative sense. Does this address your concern?
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?
"Pharming" is a vague term because it's not well-defined. The term
covers DNS attacks, TCP hijacking, malware written in Javascript, and
even look-alike names in search engines. Yes, so-called pharmers attack
DNS, but that's a part of what they do.
What we mean to say is that while we take DNS attacks seriously, DKIM
is intended to provide a similar level of security to outgoing mail to
that normally associated with incoming mail. An attacker who attacks
the DNS threatens the incoming mail today. That does apply to outgoing,
DKIM-protected mail, but the solution is the same for DKIM and MX
records.
S 9.5:
Wouldn't one defense against this be to match the To: lines?
Yes, but that's not a complete solution. We have to handle BCC as well
as To, and in that case, To has nothing to do with the actual BCCed
recipients.