ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] The limits of DKIM and SSP

2007-12-10 06:44:19
Scott Kitterman:
On Sunday 09 December 2007 10:07, Wietse Venema wrote:
After yesterday's massive agreement, today I'll expand some of my
statements with examples, and expose some limits.

Statement 1

With DKIM, The Signer Domain says "I signed this mail".  It does
not approve content, or state that content is benign.  The receiver
decides whether to give this signature preferred treatment.  There
is little or no controversy about this aspect of DKIM.

Having the bank's Signer Domain in my local address book, I can
distinguish between mail that has The Bank's signature (known to
be good) and mail that does not. When I get mail from a criminal
bank with a name and logo similar to that of my bank, the criminal
Signer Domain won't match any bank that I know I have a business
relationship with, and I can treat it accordingly.

Although I wrote that signers make no statement on content, there
are valid reasons why a signer might want to do so.  For example,
an email security service provider might want to say "I signed this
mail" and thus offer assurance that mail is free from malware. Of
course they would leave any pre-existing signatures intact.

Statement 2

With SSP, The Sender Domain says "I send such and such mail":  if
any is signed, or not signed.  This is primarily relevant for mail
without valid signature by The Sender Domain.  There is little or
no controversy about this aspect of SSP.

Agreed, particularly the "without valid signature by The Sender Domain".

Some position SSP as a tool against phishing. For example, SSP can
make statements about mail that claims it is sent in The Sender
Domain's name, urging receivers not to open any letters that lack
a valid signature by The Sender Domain.

Unfortunately, this protection is effective only under the assumption
that the bad guys are stupid; namely that they will try to send
mail in the name of my bank without a valid signature by my bank.
But criminals don't necessarily play by the rules.

I disagree.  I think that while the difference is small, I believe there is 
worthwhile benifit to preventing what I would call exact domain forgery.  
This is not a complete solution to phishing (I'm not sure such a thing 
exists), but one small piece.  While the difference between (for example - I 
didn't check to see if Paypal owns the alternate I show here) paypal.com and 
paypa1.com is small, it's a step.

Specifically, SSP statements by my bank won't protect ME against
mail from a Criminal bank with a name and logo similar to that of
my bank. The Criminal bank will make it 100% SSP compliant and will
specify the strictest policy settings. Just like the real bank,
the Criminal's SSP will say "Trust me. I am a high-value target".

Agreed.  Neither (necessarily) will the address book trick you describe in 
Statement 1.  The address book trick is only one social engineering trick 
away from being on the good list.

+------------------------------------------------------------------+
|Why would I believe the SSP from my bank, and not the SSP from the|
|criminal bank? Based on SSP alone, both have equal credibility.   |
+------------------------------------------------------------------+

Why would criminal bank's SSP matter?  SSP doesn't exist to help make positive
assertions about good messages.  It exists to identify messages that fall 
outside the senders policy (or whatever we decided the P stood for).  Trying 
to assert "Passes SSP" as a criteria for acceptance would be a poor idea.

Does the Bank's SSP matter? I assume your answer is "yes".

My point is that SSP alone cannot distinguish between mail from my
Bank and mail from a Criminal who pretends to be a slightly different
bank.  It distinguishes only the stupid criminals who send mail in
the Bank's name without signature by the Bank.

As discussed under "statement 1", mail from the criminal is easily
exposed with a simple query against my local address book. The
criminal Signer Domain won't match any banks that I know I have a
business relationship with. I don't even have to go to an external
reputation service for that.

Conclusion

We have a paradox where DKIM-BASE does not promise protection
against phishing attacks, but it's near trivial to use for that
purpose with a local address book; while SSP protection against
phishing can be sidestepped near trivially because it is grounded
in statements by a Sender Domain whose trustworthiness is unproven.

Assuming SSP asserts something positive beyond what DKIM asserts.  It doesn't.
It allows a negative to be identified.

It is not in the Bank's interest to say negative things about the
Banks mail.

Likewise, it is not in the Criminal's interest to say negative
things about the Criminal's mail.

SSP alone does not distinguish between mail from a Bank and mail
from a Criminal who pretends to be a bank. That is SSP's dirty
little secret.

This was my final attempt to illustrate this fundamental problem.
I can lead the horse to the water but I can't force it to drink.

        Wietse

In other words, SSP needs an external service to attest that the
Sender Domain's self-declared SSP does indeed represent a bona fide
business.  Supposedly, criminals won't be able to purchase such
attestation.  This is the dirty secret behind SSP.

I disagree.  I think it's the other way around.  I think without SSP, some 
additional secret secret sauce (could be a list of banks you deal with), DKIM 
buys you little.  With SSP there is a complete protocol set available that 
allows some subset of 'bad' messages to be identified and dealt with 
appropriatedly.

In reality, I think that you are correct and the bad guys will be deterred 
from sending messages exactly forging domains publishing restrictive SSPs.  
This will be a victory (albeit a small one).  
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html