At 05:37 PM 4/5/2005 -0700, Douglas Otis wrote:
On Tue, 2005-04-05 at 15:53 -0700, David MacQuigg wrote:
At 08:19 AM 4/5/2005 -0700, Douglas Otis wrote:
The current draft-schlitt-spf-classic-00, Dec 2004, sets a maximum of 10
lookups. There is still a risk of abuse, even with 10. See my previous
response to John Leslie on the DNS load question.
The rr.com record was initially in spec at 78 DNS lookups. You have
misread this poorly phrased limit in Schlitt's draft. This is a limit
of 10 mechanisms that perform DNS lookups. Each mechanism may employ 10
elements that require a lookup. That would be 10 x 10 or 100 plus the
initial record. There is also a reverse DNS mechanism requiring
comparison to a forward DNS lookup against any number of items returned
by each element. It would be hard to put a limit on such a
forward/reverse comparison process, but it could easily exceed several
hundred lookups.
You are correct. 10 queries is not an overall limit. I misread the
draft. There is some talk on spf-discuss of setting a lower limit, but
nothing yet approved. At the very least, they should make the maximum
number of queries a parameter that can be easily set at a receiving
MTA. When things get busy ( or in a DoS attack ), mail that authenticates
with one, or just a few queries, will get through, and the rest will have
to try again later. This will be the stick that gets domains to simplify
their SPF records. The carrot will be a nice SPF record compiler, that is
easier to use than creating records in a text editor.
As for the "baggage" in SPF, I think that will eventually disappear. SPF
made a mistake (in my opinion) by adding some sophisticated features with
potential for abuse. They may have had to do this to gain acceptance from
mail system admins who would refuse to adopt SPF if even the smallest
change was required in their bizarre mail setups. Whatever the reason,
SPF
is now having to backpedal and discourage the use of these features.
There is no ability to back pedal without publishing a different record
with a different algorithm.
Changing the algorithm (deprecating the risky mechanisms) would be a last
step, done only if the first steps don't solve the problem. The first
steps will be encouraging the use of simpler records, setting lower limits
on the total number of queries allowed, and allowing those limits to be
lowered even further when an MTA is overloaded.
This has to be done in a way that doesn't break existing setups. The new
"mask" feature, if designed properly, should allow most authentications to
be done in one query, and still keep the old SPF mechanisms if more
queries
are necessary. This should provide a smooth migration path from the
current complex syntax to a much simpler list of IP blocks. Eventually
the
old syntax can be deprecated.
Eventually signatures should remove the need to categorize all the
addresses for an entire mailbox-domain. There remains the problem seen
with forwarding and some list servers. Signatures and CSV can keep the
number of lookups to a minimum, while conquering many problems still
ignored by SPF/Sender-ID. CSV and signatures provide authentication,
while not assuming universal adoption or intervening security.
I think the ultimate combo will be a quick IP check at each hop, followed
by a signature check at the end. Both the quick check and the sig key
should fit in one stable, high-level DNS record. Stable allows it to be
cached for days. High-level allows one DNS record to provide the
authentication information for an entire domain.
The level at which the DNS records are kept should be at the discretion of
the sender. This is the main worry I have with CSV. It will force a
company like rr.com from one short record in a central DNS server to
thousands of records in servers all over the country.
And how does this overcome the forwarding problem? How does this
utilize the advantages gained by a signature? CSV still provides the
most expedient means to obtain an authenticated domain at each hop.
Reputation based upon an authenticated entity is the only safe means to
abate abuse. No mailbox-domain is authenticated using SPF. SPF only
indicates the client has been authorized. Authorization is useless from
a reputation standpoint. SPF does not prevent forgery.
I agree with you that SPF has a problem with forwarders. The faulty
assumption is that the sender will always have a prior arrangement with
the
forwarder, or at least be able to count on the forwarder not moving things
around too much. There is lots of wailing when this just doesn't
happen. The latest culprit is blockbuster.com. I think the SPF folks
will
eventually realize they have to authenticate each hop independently.
CSV got it right on how to handle forwarders. I think there is still a
ways to go on reducing the DNS load. ( See my reply to John Leslie.) I
don't like having to set up DNS records for every server, but that is just
an inconvenience. If I had to do it for a hundred servers, I would
probably write a little script.
The real trouble for SPF happens when Microsoft et al applies reputation
to the mailbox-domain. False assumptions of authentication will become
apparent, by injuring typical email consumers. One must also hope SPF
exploits do not become endemic as well.
It is hard to know how this situation will evolve, which problems will turn
out to be serious, and which will find a workaround. We need a standard
authentication protocol that does not give any one method a lock-in. Then
if SPF/SenderID turns out to be as big a problem as you anticipate, the
switch to CSV will be easy.
--
Dave
************************************************************ *
* David MacQuigg, PhD email: david_macquigg at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *