|
|
|
26 July
2005
A lot has happened in the last year, but at last the world has
stabilized enough to be able to write an article about progress in
the field. A group of us have been working on unifying two
signature-based email authentication systems into a single system:
Yahoo!"s DomainKeys (DK) and Cisco"s Internet
Identified Mail (IIM). The unified system is called DomainKeys
Identified Mail or DKIM (pronounced “dee-kim”)
for short.
DKIM provides a way for an email message to be signed so the
receiving domain can know the sending domain, even if it has been
forwarded through intermediate domains. It is an important part of
email infrastructure that is already being used to solve spam and
email fraud. We have also been careful to make it
upwards-compatible from the original DomainKeys system.
The cross-industry group working on DKIM includes Alt-N
Technologies, AOL, Brandenburg Internetworking, Cisco, EarthLink,
IBM, Microsoft (both the Exchange group and the Hotmail group), PGP
Corporation, Sendmail, StrongMail Systems, Tumbleweed
Communications, VeriSign, and Yahoo!. We want DKIM to be an
approved international standard, not simply a de facto standard, so
we are submitting the draft specification to the Internet
Engineering Task Force (IETF) this summer.
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.
Consequently, we are using a different formatting system that
unambiguously shows which signatures mean what and allows for
content-signature systems such as OpenPGP and S/MIME to work with
DKIM. Had we adapted one of the previous systems, we would have had
to expend a lot of effort working on mixing and disambiguating the
different signatures and what they cover and mean. Because DKIM
signatures are used differently and mean different things than
content signatures, it is best if they are a separate system.
How DKIM
works
DKIM"s basic operation is simple. Before a mail transport
system sends an email, it creates a digital signature of the
message and some set of its headers. That signature and a
description of what is being signed are put into the
message"s headers.
DKIM is also upwards-compatible from the original DomainKeys
system. DomainKeys is already being used by a number of ISPs and
email senders, including Gmail, Yahoo!, and others. Look through
your mailbox and see if you have a message from them, and then look
at the headers. You"ll see the DKIM signature there.
When the message is received, the public key for the message is
retrieved from DNS for the signing domain. The receiver verifies
the signature and then processes the message.
DKIM also includes policy components, which are rules about how
the signatures are to be used. For example, a signer can state,
“I sign all my messages, and if you find an unsigned
message that claims to be from me, reject it.” These
policy components help signing domains tell receiving domains what
to do with the messages.
False dilemmas, false
competition
Unfortunately, there has been and still is a good deal of
misunderstanding about DKIM and other technologies that are
positioned as false competition. Now that we have released the
first integrated DKIM specification, there will no longer be
discussions about DomainKeys versus Internet Identified Mail.
However, there is still false competition between DKIM and
SenderID.
SenderID is a unification of Sender Policy Framework (SPF) and
CallerID that is similar to the unification of DK and IIM into
DKIM. It is a path-based form of authentication. In SenderID, a
domain states which host addresses it will send mail from, and thus
allows the receiver to know something about the message"s
authenticity based on its network source, rather than its
content.
Some people still look at email authentication as a competition,
rather than as the coexistence of complementary technologies.
SenderID and DKIM work well together, in fact, better than either
works alone. It is valuable to have both network-level, path-based
authentication as well as signature-based authentication that
travels with the message even as it is routed. The situation
isn"t “either-or,” it"s
“both-and.”
Building on authentication
Authentication is part of the system, but it isn"t
the whole story. Traditionally, security includes not only
authentication, but authorization as well. Authentication tells us
who an entity is, and authorization tells us what that person is
allowed to do. For example, a keycard entry system may not let you
through a given door, even though it knows who you are. After your
bank has authenticated you, you are still authorized to spend only
the money in
your account. In the case of email, authorization is
somewhat vague: it refers to who is allowed to send you mail.
Amazon is more likely to be authorized to send you mail than Miriam
Abacha of Nigeria, for example.
In email security, we"re phrasing authorization issues
as reputation issues: Who is that sender and how likely is it the
end recipient wants to see that message? Neither the DKIM nor
SenderID authentication system has built-in authorization and
reputation. However, both permit authorization systems, reputation
systems, blacklists of known bad senders, and whitelists of known
good senders to become far more effective. Although it"s
possible for bad senders to authenticate their email, fighting spam
from authenticated spammers is much easier.
Beyond this, authentication permits other sections of the
Internet infrastructure to become involved. Part of the problem in
email security is that the bad actors buy many domains and use them
to send bad email. Authentication allows us to start tying the bad
actors to their bad email, while protecting the good actors.
How to get
involved
As I mentioned earlier, DKIM is upwards-compatible from
DomainKeys. If you run email systems, consider running DomainKeys
now so you can start getting used to this process. If you
don"t want to run it, at least look at DomainKeys because
it will give you an idea of what is to come.
If you are adventurous, look at the existing DKIM
implementations. We already have three interoperable
implementations of DKIM, from Alt-N, Cisco, and Sendmail.
If you use email systems, encourage the people who run your
email systems to start looking at DomainKeys or DKIM. Although DKIM
is not yet available for everyone to deploy, it is worth planning
what you will do because email authentication is here even if it
isn"t yet complete.
If you don"t want to implement anything yet, but you
want to be prepared, start examining your email infrastructure.
Examine which systems will send email on your behalf. Examine how
off-site employees, contractors, outsourced business partners, and
other people use email that comes from your domain. Whether you use
SenderID or DKIM, you need to know who is sending mail on your
behalf. After that, you need to find where email is being received.
The latter task is easier, but each can have surprises.
Everyone"s email infrastructure is set up ad-hoc and
works in ways its staff doesn"t know--a result of the
nature of email. Authentication is going to force users to figure
out how email is set up. Authentication is good for everyone
because it will finally make a dent in spam and phishing, but it
also means that we have to understand our email systems, which we
never had to do before.
Background
Reading
“DomainKeys
Identified Mail (DKIM),” 2005
Evers, Joris,
“Antispam
spec sets off on path to standard,” July 11, 2005,
CNET News.com
Yahoo! Anti-Spam Resource Center,
“DomainKeys:
Proving and Protecting Email Sender Identity”
|
