ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] user level ssp

2006-09-07 14:25:48

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.  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.

The fact that your email shows up at my email server signed by your  
email server is all the protection I need or want.  At that point,  
I can use my own internal policies to decide if your domain is  
trustworthy or not, based on our experience with you and/or your  
internet reputation.

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.
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.

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.

A large domain like Yahoo! will perpetually have a moderate  
reputation, largely due to their size and ease of obtaining an email  
account.  Does this mean that Yahoo! can never be trusted on the  
basis of their domain?  Most would trust a message that Yahoo! backs  
with a high level of assurance.  Perhaps admin(_at_)yahoo(_dot_)com could  
receive a high level assurance.  This high level assurance might be  
deduced by specific email-address policy this email-address is  
"STRICTLY ASSURED TO BE SIGNED."  A message signed by Yahoo! and  
given a high level of assurance should become a minimal requirement  
before anyone follows actions suggested in an email, at least without  
other out-of-band information.

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.  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.  Yahoo might
even catch the problem on an outgoing filter, noticing that it looked
like a forgery of it's own admin mail.  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.

Why would bigbank.com sign a message from accounts(_at_)bigbank(_dot_)com if 
 
it wasn't valid?  If it is signed, then bigbank.com is certifying  
that it is valid.  That's enough.

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 is not DKIM's place to solve the internal security problems of  
bigbank.com.  And I don't see how user-signing could help, even if  
it was DKIM's job to do that.

It is not user policy, but email-address policy that is significant.   
If BigBank.com knows that <accounts(_at_)BigBank(_dot_)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 trust.

BigBank.com can however make extremely strong assertions about  
<accounts(_at_)BigBank(_dot_)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(_dot_)com?
The signature itself without annotations is sufficient to prevent any
lookalikes on the left side of the @.


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.
2. DKIM can be strong enough to encourage users to enter personal
   information into emailed HTML forms.

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.

Second of all, at this juncture, no reputable company has any business
requesting personal information via email.  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".

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.

        tom
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html