On Sep 7, 2006, at 2:13 PM, Thomas A. Fine wrote:
Douglas Otis wrote:
While there are a limited number of IP addresses, there are also
an unlimited number of new and used domains that can be obtained
at little cost. The concept that DKIM in conjunction with white/
block listing will make a dent in the amount of spam is simply
wrong. DKIM should improve reporting and help prevent spoofing,
nothing more.
Little cost. Compare this to an infinte number of totally free
addresses and domains.
When is a different IP address easier to obtain than a different
domain name?
That's the current situation. I'll take the improvement.
Especially since each domain a spammer buys is good for a matter of
hours at best before it is distributed to blacklists worldwide.
In many cases domains have already been acquired where the bad actor
is thrilled to have a minor investment buy them hours of spamming.
Block-listing by domain name is more perilous than by IP address.
Errant blocking of an IP address may disable a server, errant
blocking of a domain name may disable an entire enterprise. : (
To prevent disruption of email services, your system will also
continue to accept messages that are not signed, and that have
signatures that appear to have been damaged. Perhaps only when an
email-address domain makes an extreme assertion all their messages
are assured to have a perfect signature, would there be a basis to
block those messages. Every other look-alike or cousin domain
will still be accepted. Without annotation applied to signed
messages, the recipient will not have been helped at all.
There is nothing extreme about signing every outgoing message. And
if they do that, of course I'll reject their unsigned or invald email.
You would discard messages from an mailing list? Perhaps this is not
the desired outcome for all but a few email-addresses being used. : (
Disruption of email services? Email is constantly disrupted, and
people get along. Right now the biggest cause of non-delivered
messages is false SPAM positives. If a domain promises to sign all
messages and messes up now and then, they'll still have a better
delivery rate than going through spam filters.
That really depends upon the expectations recipients have for DKIM.
At this point, serious concerns should be raised about the integrity
of email-delivery when policy is published. This is unfortunate, as
policy can provide an ability to better inform recipients.
Look-alike domains with valid signatures can be added to a public
blacklist and forever more be blocked by anybody who cares to do so.
There is also an unlimited number of look-alike and cousin domains.
Phishing tactics are often complete within a brief period of time,
typically before any bill is paid. IP address block-lists are
already in place, and can be applied prior to the data phase of the
message. Why would MTA operators switch to using RHS block-lists?
Perhaps Yahoo! wishes to request their users to go to a web-page
and update a compromised browser toolbar. If this were a message
from a bad-actor holding one of their accounts and people
responded based solely upon the Yahoo! signature, this would be
very bad news indeed. High level assurance annotations offer
vital protections.
This is yahoo's problem, and they can deal with it.
Selective email-address annotations offer a proactive solution.
The mail came from one of their own accounts, so they can trace all
mail from that account and contact everyone who received that
mail. The bad actor won't keep the account for long, and won't get
to send many messages.
The DKIM signature, by design, is not related to the envelope and can
be carried by any MTA. Who ends up receiving these messages might be
under their control, assuming messages are not forwarded. Yahoo! may
refuse to accept messages that appear to be signed by Yahoo!, but
this could cause a conflict when a message is being forwarded, as
example. Once an exploit has been reported, perhaps Yahoo! could
retroactively defang messages already in their recipient's
mailboxes. That unfortunately is reactive and unpleasant, and people
often refang because they think the process is mindless. Obtaining
new accounts does not represent a major impediment either.
Yahoo might even catch the problem on an outgoing filter, noticing
that it looked like a forgery of it's own admin mail.
The bad actor do not need to forge any specific email-address.
Without annotation conventions being established, any social
engineering trick would likely lead to successful spoofing. : (
Yahoo might also notice that this user has sent 1000 messages in
the last two minutes, and that maybe it should just hold onto all
of those messages for a little while. Yahoo could treat all new
accounts with suspicion for some period of time. There are so many
cool things that yahoo could do if they wanted to stem the tide,
and protect the reputation of their own email.
It is common for a Bot army to be 50,000 wide and message amongst
themselves to appear normal. Messages could be variations on a
general theme that reference an apparently harmless website using
randomized links when being signed. At 3:00 AM, the bad actor flips
the switch, and now it looks like a friendly website offering advice
in how to reinstall a defective Yahoo! toolbar. The HTML content now
looks official, and the message is signed by Yahoo!. : (
One should not expect the recipient to be able to even recognize
the email-address. One should not expect all messages being
signed will
have valid email-addresses, or that they are from trustworthy
sources either. A signature alone is never enough.
All these these are true separately but not together. If I get
mail from bigbank, I expect to recognize the address, and I expect
the address to be valid, and I expect it to be signed, and I expect
the signer to be bigbank. After all that, I'll believe it's
proably from them, although even then not enough for anything
really sensitive.
It sounds as if this depends upon visual acuity. Such dependence is
highly perilous.
It is not user policy, but email-address policy that is
significant. If BigBank.com knows that <[EMAIL PROTECTED]> is
trustworty, but that other emails-addresses are less trustworthy,
how should that be conveyed? By not signing the other messages?
That would be silly.
If it doesn't trust them internally, it certainly should not sign
them. It would be silly TO sign an outgoing message that you can't
trust.
There are certainly different levels of assurance a domain may wish
to make regarding their entire domain, versus a specific email-
address. When the email-address is recognized by the address-book,
then the recipient has established cause to trust the email-address
out-of-band. When a trusted list of domains is being used to apply
annotations, then the application of annotations on specific email-
addresses would be desired.
BigBank.com can however make extremely strong assertions about
<[EMAIL PROTECTED]> that would be highly disruptive when
applied to other addresses. This could be done solely to increase
the level of assurance annotations this message receives.
Assurance annotations offer a proactive means of preventing broken
signature and look-alike attacks.
How does it prevent look alikes? What's to keep a phishing attack
with valid keys and super secure annotations from [EMAIL PROTECTED]
Bank.com? The signature itself without annotations is sufficient to
prevent any lookalikes on the left side of the @.
Imagine that a trusted-domain list offers a gold star next to
specific email-addresses that is established by way of a policy
assertion. Recipients seeing these messages don't need to know that
the gold star is being applied to the <[EMAIL PROTECTED]> email-
address. They simply see the gold-star. Look-alike domains are not
found in either their address book or within a list of trusted
domains, and hence never receive the gold-star annotation.
The thing I find amazing in all of this is that simoultaneously,
you believe these two things about DKIM:
1. DKIM can never be good enough to trust as part of a domain-wide
delivery filtering mechanism.
True, there are too many exceptions required, and replay can be
problematic.
2. DKIM can be strong enough to encourage users to enter personal
information into emailed HTML forms.
True, when annotations are properly applied, following the actions
recommended in the message would be less hazardous. If their toolbar
does need to be updated, this method of notification should be
reasonably safe. Of course, the user should still check certs on the
web site, use a VPN or tunnel for DNS when running a wireless
connection, etc. etc.
First of all, mail gets lost. ALL THE TIME. Your mail, my mail,
everybodies mail. Sometimes NOBODY EVEN NOTICES. The rest of the
time, it just gets resent. Who cares? Transitioning to a system
where a domain promises to sign every message is not that hard,
because SO WHAT if a little mail gets lost in the process. Mail
servers are upgraded regularly, configurations are changed
regularly, and mail gets lost regularly.
I was not the person that raised the transitioning concern. DKIM
will not see broad adoption if it causes delivery issues. Policy
must tread very carefully to avoid these pitfalls.
Second of all, at this juncture, no reputable company has any
business requesting personal information via email.
They may offer a friendly link to save you the effort of typing the
domain. A bad actor simply does the same thing.
It's like receiving a phone call from a charity and giving them
your credit card on the spot. And with DKIM, it's like trusting
them because caller ID said plain as day that it was the "Amer
Cancer Ass".
There are valid cases where information wants to be distributed to
recipients. "Your mortgage payment is due. Automated payments can
be established at our website at <http://helpful-link/>." While this
message is not a phish, the user should not click on the link. Some
provider's defang all links unless there is reason to trust who sent
the message. DKIM offers some danger when people trust too much of
the domain's content. Policy can make this trust much more selective
and safer.
Me - I pick up the phone if the caller ID is not blocked or
unknown. But I don't give them my credit card in any case.
Heck, my bank pulls this stunt. They notice unusual activity on my
account and call with a blocked number asking me to identify myself
by with personal identifiers. Everyone knows the list. When I ask
how they are listed to call them back, the person says this is not
possible, they are in a phone exchange without extensions. It is not
surprising everyone is so prone to spoofing.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
