Jon Callas <jon(_at_)callas(_dot_)org> wrote:
On 30 Jul 2005, at 9:56 PM, EKR wrote:
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.
Agreed.
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.
I disagree, because they go to the question of whether its a useful
technique.
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.
You can't ignore the fact that the reason people are interested
in this is as part of a spam/phishing filtering system. In
such a system, the value of reducing identity forgery is
primarily to enable whitelisting, which has the purpose of
reducing false positives. So, it needs to be asked whether that
is a useful technique.
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.
Right, but why is that a different problem from the one that
PEM et al. attempt to solve? I.e., why can't you use the same
protocol for secure messaging and for this application?
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.
Yes, but it would give you a system constructed of generic components,
which is always a good thing.
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.
Yes, that's fine, but cryptographically there's no important difference.
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.
Sure, but why doesn't this all just imply that we should junk S/MIME and
OpenPGP and replace them with DKIM?
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.
Extremely minimal value, I would argue.
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.
Yes, but that's not what this text says. You explicitly don'[t
contact the signer, but rather some potentially entirely different
machine operated by a different person. This isn't a technical
issue but one of writing clarity.
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?
Well, it's also true that adding >64 bytes to the message imposes
higher digest costs, but it's generally regarded as insignificant.
I tend to put the verification costs in this category. That said,
I don't really care.
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.
Attacker generates message A (spam) and message A' (not spam) that
collide. He sends A' through the MTA, gets a signature, and then strips it off
and sends A to the victim. It's slow, but it is an attack that doesn't
require preimages.
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.
I'm not saying the above is a serious security risk, merely that your
analysis above is inadequate.
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?
No, because initially currently many senders don't have any such
policy published. They just don't sign their messages. The important
question for the recipient is how useful a signal a message being
signed is. If it only reduces the false positive rate for spam
(back to that again, but that's the use case) then the incentive
to use it as a signal isn't very high.
-Ekr