Why is anyone going to implement DKIM at all? What might their
motivation be?
To protect their domain from being spoofed. The only logical long-term
choice for a domain to achieve this protection is an "all-signed" SSP.
Here's a summary of why:
protection SSP/all-signed user-signing
-------------------------------------------------------------------------
entire domain from spoofing yes no
against phishing yes sort of
against lhs look-alikes yes no
against rhs look-alikes no no
spam false positive losses yes in part
reduces spam eventually no
And here's the details:
Protects entire domain from spoofing
If a domain signs every piece of mail it generates, and says publicly
that it does this, then a mechanism is in place for anyone spoofing any
address for this domain to be dropped. If a domain does not sign
everything, then any unsigned real addresses can be spoofed, and in all
cases non-existent addresses can be spoofed.
Protects against phishing
A phisher can not generate any email from a fully-signed domain. A
domain that is partly signed is only protected against attacks from
those addresses that it decides to sign.
Protects against lhs look-alikes.
The left-hand-side of the address can not ever be spoofed in a
fully-signed domain, regardless of whether the lhs in question is real
or fake. With only user-signing, any non-existent address can be
faked. So if you've protected "accounts", soemone could still spoof
"account" or "acounts" or "accuonts" or "billing" or
"account_administration", and you'd never possible predict everything
in advance.
Protects against rhs look-alikes.
Neither scheme can do this. If the right-hand-side (the domain) is
a look-alike, then the message can be signed by the look-alike domain.
They can even sign it with extra double-secret protection from
their fake domain and the user will see the gold seal of approval on
the fake look-alike email.
You could make an argument that once all-signed policies become common,
it will become much easier to block mail by domain, which will
allow improved protection against rhs look-alikes.
Eliminates false positive losses from content-based spam filtering.
Once a domain signs everything, all of it's legitimate email may
be accepted by receivers who trust it without content filtering.
If only some addresses are signed, then only those addresses can
be accepted without filtering.
Reduces spam
Every time another domain decides to protect itself by publishing an
all-signed policy, the universe gets marginally worse for spammers,
and marginally better for spam fighters. Once all-signed policies
become the norm, spammers will be vastly easier to fight, sitting
out on the fringe of the internet, instead of being the everywhere
at once.
What I hope I've showed is that we can get to that point without
relying on the goodness in domain-owners hearts to do this as
a public service. There are several legitimate and real protections
domain holders will get from an all-signed policy, and only
from an all-signed policy, that make it worth the effort.
"But it's too hard", you say. You're forcing them to make too many
institutional changes. First of all I'm not forcing them, I'm
motivating them. And so what? They may want us to magically drop in
and solve all their problems with the wave of the wand, but they can't
have that. When they see the obvious benefits, and the costs
associated with doing nothing, they'll make the changes they need to,
because they always do.
Look at network security. When cracking systems became a popular
past time, did people throw up their hands and say "we'll never
stop them, so lets do nothing"? Or did they bite the bullet and
make hard choices that were costly and time-consuming to implement,
and forced annoying changes on everyone? They did the latter.
The changes were major - users had to stop using telnet and rsh
and rlogin and rexd, and start using ssh, and later VPN. They
made the adjustment.
Are networks completely safe? Of course not. DKIM can never stop all
SPAM. It can't stop all phishing. It can't completely fix any
problem. Locks on buildings don't stop burglary either, but they're
still widely used, and very successful.
"But what happens when my signed email gets out in the world and
gets corrupted and doesn't get delivered and it isn't my fault?"
Then it isn't your fault. Complain to whoever broke your mail and
make them fix it. If they won't fix it, complain to the list, and
have them move it to a service that works properly.
"But how can users sign mail from outside of the domain?" If you trust
them, you can give them a key - it can be their own key, and this will
work without user keys per se, just within the basic DKIM mechanisms.
Or you could give them an account on your system and they could log in
with ssh or VPN. Or you could set up a secure web interface for
sending mail. And more I haven't thought of. When telnet went
away due to poor security, people still found ways to get their work
done.
"But what about SPF -all? That failed, so all-signed SSP will too,
right?" Well, when firewalls were new, a lot of them were sold on the
basis that you drop it in your network, turn it on, and you're
protected. A lot of people fell for that, but they quickly realized it
wasn't true. The problem with SPF was that it was oversold, and free.
If you paid $10,000 for a firewall that turned out was NOT turnkey, you
get the damn thing to work. The poeple across the street got theirs to
work. But SPF was free, so it's easy to give up on. Especially if
there's no one across the stree with it working perfectly. So the key
here is to market all-signed SSP honestly, to set real expectations,
and also to demonstrate large-scale working implementations.
"Ok, I'm convinced, but what about user-signing on top of an all-signed
policy?" Well, amidst all this arguing about user-signing, the only
thing I've seen that comes close to a reasonable argument is the
example of yahoo who signs mail for all of their users, but wants
special protection for admin(_at_)yahoo(_dot_)com(_dot_) That's a reasonable
thing to
want. Yahoo could alwyas have a different domain for official
business, apart from their vast unwashed masses. But desiring a
mechanism that says specifically that admin(_at_)yahoo(_dot_)com not just signed
by yahoo, but REALLLY IS YAHOO is still reasonable.
So DKIM is trying to be both a domain signer and a PGP sort of thing
that's better integrated than PGP. Personally, I see that as a
problem. domain signing is something that ought to happen at a layer
that's the email equivalent of the transport or session layer in the
OSI network model. Where genuine user identification belongs more in
the presentation or application layer. Specifically this is a problem
because for domain keys, I'd like to sign the envelope header, and I'd
like to strip out old signatures and add new ones as needed, which
would alleviate 99% of mailing list issues. But genuine user
identification has to survive life of message, not just through
end-to-end connection sessions. As such, it probably doesn't
belong in the headers at all. So the DK and the IM of DKIM, while
seeming to be extremely similar are actually very different from one
another. They share alot, but they are not the same.
Maybe that's the source of all the conflicts here.
Maybe it's the fundamental problem with DKIM.
tom
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html