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
