One of the problems with this attempted 'fast tracking' of Sender-ID is that,
AFAICT, there has been no systematic catalog made of the threats against which
Sender-ID is supposed to defend, and no analysis of its ability to defend
against those threats - particularly when the threat-designers adapt them to
take Sender-ID into account.
Here is a first, simplistic attempt at what such a catalog might contain,
collected mostly from other people's postings.
Because of time and space restrictions, I'm going to just present these as
personal assertions. There are, of course, special cases and boundary
conditions, but I've tried to be as fair as I can about the broad thrust of the
strengths and weaknesses of Sender-ID.
My purpose is to cause some readers, perhaps those who have recently joined this
list and are offering the support of the large organisations they represent,
cause to pause for a minute, and ask their expert colleagues if 'this unknown
Brit' could possibly have a point.
In the brief list below I am considering only:
- Consumer users
- Who are using current versions of MS Outlook Express (OE)
- Who do not know how to access or interpret the message headers.
I guess that this probably covers the majority (i.e > 50%) of consumer users in
the world.
I am also assuming that the 'bad guys' have read and understood Sender-ID and
so will have made whatever simple adaptations are necessary to continue to
unleash their mischief.
I have also assumed that the 'good guys' will have done all they should - i.e.
implemented Sender-ID records with '+' records on their outbound MTAs and '-all'
(or equivalent) for all other sources.
===================
* Sender-ID blocks Phishing eMails - WRONG
A Phisher need only use the headers
From: Big Bank Security <security(_at_)bigbank(_dot_)com>
Resent-Sender: phisher(_at_)badguy(_dot_)com
and have a legitimate domain: 'badguy.com" with SPF records. The PRA test will
'pass' badguy.com, but there is no way to tell that user that test has been
done, let alone what address was actually tested.
The user will see
"From: Big Bank Security"
on her OE display.
See David's post of an hour or so ago <mazieres(_at_)gmail(_dot_)com> for
further detail.
=====================
* Sender-ID lets genuine senders show they are not Phishers - WRONG
The Big Bank can send a message with a header
From: Big Bank Security <security(_at_)bigbank(_dot_)com>
The PRA test on 'bigbank.com' will pass and the user will see
"From: Big Bank Security"
on her OE display.
This is exactly the same as she saw when the phisher wrote to her, and is also
exactly the same as if the bank did not implement Sender-ID at all.
======================
*Sender-ID stops spam - WRONG
All a spammer has to do is register a domain and set up SPF records.
As far as any MTA using the Sender-ID test is concerned, all spam which can pass
the Sender-ID test is allowed through.
Sender-ID itself has no ability to distinguish spam from ham.
Some people posting to the spf-discuss list believe they can detect spammers
amongst the early, enthusiastic adopters of SPF!
========================
*Sender-ID stops viruses - WRONG
Recall that I am assuming that the virus-writers will adapt to the presence of
Sender-ID. A virus writer who gains access to a 'trojaned' PC will cause the
outbound mails to be sent through the SMTP server of the machine's normal ISP
(if the trojan horse can access the address list, it can, in many cases, also
work out the address of the ISPs' SMTP server).
Many ISPs will accept the mail as genuine with no further checks, so the
virus-carrying mail will emerge from the ISP appearing exactly like a legitimate
mail from the same end-host, and will pass any SPF tests the ISP has set up.
The only inconvenience to the virus-writer is that the message rate may be lower
than when he used to send mails directly to the victims.
===================================
So why use Sender-ID?
Well, Sender-ID, just like other header forgery detection system such as
SPF-Classic, forces some of the bad guys to have to use their own domains, and
to set up SPF records. This introduces an additional element of traceability,
via the domain registration process, and perhaps an element of stability (they
will have to use the same domain several times) giving reputation systems a
better chance to spot them.
So, used in conjunction with _today's_ Outlook Express MUAs Sender-ID's PRA test
is just as good / bad as the (licence-free) SPF test.
Oh, and Sender-ID has a security vulnerability (a weak defence against
'bounce-bombs' ) which SPF has a defense against.
In the long-term it might be possible to evolve Sender-ID _and_ a new generation
of MUAs to provide users with a display which they could be educated to use to
detect Phishing attempts.
You will have to use your own judgement of Microsoft's product cycle times to
decide how long is will be until, say, 20% of the installed consumer base would
have this feature before their eyes.
I myself would be amazed if even this small level of penetration could be
achieved before 2007.
-----------------------------------
So - just what benefits are you selling to your organisations when you support
this current, rushed version of Sender-ID on their behalf - and are you _sure_
that you can deliver on those benefits?
Are they in your personal objectives for 2004?
Do you feel lucky?
==========================
Personal statement re: DEPLOYment
At present my plans are to implement SPF in our special-purpose MTAs, which are
designed and implemented within my own organisation.
Since, in the short term the majority of my users will continue to use Outlook
Express and similar Sender-ID-unaware MUAs,
and since Sender-ID provides no technical benefit over SPF in this time frame,
and since Sender-ID has a security vulnerability which is not present in SPF,
and since Sender-ID is encumbered with a licence which appears to require me to
notify Microsoft of my business intentions,
and since that same licence may be withdrawn by Microsoft at any time,
I have no business justification for implementing and deploying Sender-ID at
this time.
Chris Haynes