On 2 Aug 2005, at 6:34 PM, Eric Rescorla wrote:
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.
Okay, then help us say the right thing.
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.
I'm sorry for giving the impression I'm ignoring it. I'm not.
I'm trying to say that it *starts* with white listing and goes on from
there. There are already people building on top of DKIM. There is
already someone doing "Accredited DKIM" (ADK) which layers
certification and other things on top of DKIM. There are other people
doing reputation services (Habeas, Goodmail, etc.) who are going to be
shifting to DKIM as the roadway they travel on.
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?
Here's what I wrote in <http://www.pgp.com/library/ctocorner/dkim.html>:
Why create a new standard?
--- ------ - --- ---------
Given that there are two existing standards that allow for email
signing, OpenPGP and S/MIME, why did we create something new? The
reason is that there are characteristics we want this system to have
that are best addressed by a new system:
* End-user transparency. We want there to be no required changes
to existing email clients and no required changes in what a user
sees. This characteristic is extremely important because there are
many email clients, and not all of them have regular schedules for
updates. It is much simpler to put the necessary changes in the
servers and then add features to the clients. However, we also want
to permit email clients to add in indication of DKIM-signed
messages. Yahoo! is already doing this in its webmail systems,
noting when a message has been authenticated.
Similarly, we don't want the users to see anything new. This is
particularly important to Internet Service Providers (ISPs) that
don't want to answer support calls from users asking what the
changes to their email mean. Users shouldn't be surprised.
* No user intervention. We don't want to require end users to do
anything. Even worse than surprising them with changes would be to
require them to learn to do something new. That requirement would
doom the system to failure.
* Signatures identify sources. We want a system that does not
create issues about the meaning of the signatures on the message. If
I send you a signed postcard from vacation, you know my signature is
a personal touch, not a legal commitment to, “Having a wonderful
time, wish you were here.” That same signature at the bottom of a
business letter means something very different.
A DKIM signature means the message came from a specified source, and
nothing else. It is metaphorically more like a postmark on an
envelope than the signature on the letter inside the envelope. Each
of these has value, but on different levels. The email delivery
system does not (and should not) care about the internal signatures
on the content, and the systems that work with signed content do not
and should not care about the signatures that cover delivery.
* No certificates. For simplicity's sake, we want a system that
does not require a certificate system. There is value to having the
keys that sign DKIM messages be part of a PKI, but it is not
necessary. The signature simply covers the message transport, its
metaphorical “envelope.” We want these keys to be easy to create,
update, maintain, and expire. Note that this does not preclude using
a certificate system as an adjunct to DKIM. There are reasons to
have certificates, too. We just don't want them to be required.
* Privacy-friendly. We don't want to create new privacy concerns
in an anti-spam system. DKIM signatures are by and about an
administrative domain, not about the end user. A DKIM signature
denotes that the end user was authorized to send that mail and takes
responsibility for it, but nothing more. The end user may not even
be an actual person, but an administrative process.
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.
Okay. Are you requesting we break it up into two documents?
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?
I don't think so. Does the existence of IMAP imply we should junk POP?
I can pick other examples as well.
If we look forward into the future, say five years from now, and it
turns out that people decided that signing with DKIM has replaced
signing with OpenPGP and S/MIME, I might disagree, but hey, the market
has spoken. I don't expect this to happen, because I believe they are
different. DKIM's key-centric model, for example, makes its primary
goal, protection of messages while in transit, easy. It makes the other
problem -- relatively long-term signatures not so easy. Yes, of course,
someone can layer a PKI on top of DKIM. If they did, it might overlap
more, but that's what DKIM++ could do, not DKIM.
I suppose, too, people could like DKIM so much that they'd want to add
encryption to it, but I'm not interested in that. DKIM is a signing
system for transport protection of messages.
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.
Uh huh. But this shows that it's incremental.
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.
Suggest some text, please. What would make it clear?
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.
Are you talking about canonicalization collisions?
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.
Only if it's easy to construct A and A'. If we have something in there
that makes it easy to construct A and A', then that might be a problem.
It might also might not be a problem. One advantage of an
authentication system is that it establishes responsibility. Let's
suppose that the attacker is an AOL user and sends them out through
AOL. Receivers of the spam can complain to AOL just like they would for
any other spam from an AOL user.
Let's suppose that the attacker is using their own domain running
through a botnet. In that case, it's even easier to deal with that --
we blacklist that domain.
(One of the things that I am also advocating in other venues is that
the registrars have to start taking responsibility for who they give
domains to. If someone buys cheapdrugz4u-0000.com through
cheapdrugz4u-9999.com doesn't it look like they're up to no good? I
think that lax registration policies are irresponsible. But that's
another debate.)
In the last case, let's suppose that the attacker generates the
collision on one of my messages. My response needs to be to change my
hash algorithm, canonicalization algorithm, or both.
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.
That's not what people tell us. They tell us that they would love to
use DKIM for no other purpose than removing false positives on
content-based spam filtering. Customers of ISPs hate false positives.
Enterprises live in fear of false positives. We've asked a lot of
potential users, and they see great value in it.
Jon