[ietf-dkim] user level ssp
dotis at mail-abuse.org
Thu Sep 7 17:33:36 PDT 2006
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
> 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
>> It is not user policy, but email-address policy that is
>> significant. If BigBank.com knows that <accounts at BigBank.com> 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
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
>> <accounts at BigBank.com> 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 accounts at Big-
> 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 <accounts at BigBank.com> 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
> 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
> 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.
More information about the ietf-dkim