[ietf-dkim] Collection of use cases for SSP requirements
steve at blighty.com
Thu Nov 9 08:04:33 PST 2006
On Nov 9, 2006, at 7:46 AM, Dave Crocker wrote:
> Steve Atkins wrote:
>>> Well at least it is a start to force the phishers into using look-
>> No, it isn't. There is no way in which SSP makes this better.
>> Depending on how it's implemented by recipients there are ways
>> in which it makes it worse.
> Anything said that firmly -- and saying something many will
> consider unexpected -- really does require the details that justify
> This is a hearty "please" requesting that you elaborate.
"There is no way in which SSP makes this better."
Phishing does not require the use of the real domain and,
in current practice, some of the better phishes already do not
use the original domain (for a variety of reasons, including
the remnants of previous attempts to defend against byte-for-byte
usage of domains by those unauthorized to use them).
Most users don't look at the headers of the mail, other than
the subject line and the "friendly from", as our ESP friends describe
the comment in the From: header.
There is no common usage of a single canonical domain in
the headers of the legitimate email from many financial institutions
anyway, so even those users who do look at the From: field
have no expectation of seeing anything specific there.
SSP concentrates on protecting byte-for-byte duplicates
on the wire of the original domain in a small minority of the
contexts in which it's used. It is not concerned with different
domains that render to identical or near-identical glyphs (1-vs-l,
punycode and other approaches), it isn't concerned with
homonyms and synonyms, it isn't concerned with plausible
lookalike domains, nor does it concern itself with use of
domains in the body of the message.
If phishers chose to be similarly constrained in their concerns
then SSP would be a useful tool against phishing.
"Depending on how it's implemented by recipients there are
ways in which it makes it worse."
Any phisher can create valid DKIM+SSP records for the domain they
use. Without some sort of external trust model there is no difference
between that mail and valid mail from a bank.
If (and this is where the "implemented" bit comes in) recipient ISPs
or MUAs annotate mail in any way that suggests that mail that is
validly DKIM signed and claims that no non-signed mail is ever
sent is, in any way at all, more trustworthy than, say, non-DKIM
mail or mail with no SSP constraints that will make the phish
more plausible than it would be in an MUA which pays no
attention to DKIM or SSP.
Lest you suggest that no ISP would ever be foolish enough to
do such a thing, look at Hotmails past behaviour with SenderID.
More information about the ietf-dkim