On 6/29/2004 1:30 PM, Roy Badami sent forth electrons to convey:
I've seen it argued earlier in the life of SPF that some sites might
not wish to make their complete list of outgoing IP addresses easily
accessible, and that the exists mechanism in SPF (I guess this is what
is meant by a factored record) is of benefit to such sites. An
attacker who'd comprpomised an ISP's routing could use block records
to rapidly search for domains that list addresses in netblocks the
attacker is able to spoof. Factored records make that search much
harder.
Yup. I can't advocate removing the macro abilities of SPF. Unless we
make some progress toward showing that Classic SPF with macro abilities
doesn't create a tempting and relatively vulnerable target, then I see
CSV as necessary before SPF. Makes more sense than dropping macro
abilities.
Philip is saying in essence that the details of an attack scenario and
of CSV are beyond his comprehension at this time* and he and I appear
unable to communicate further; each of us feels we have presented our
case fully, but we are still far apart. This is unfortunate; I think if
we dug deeper we might find that SPF can withstand attack as well as
what's out there now. Philip's posts to date don't get us there, so I
think we need to agree to disagree. I don't mean anything personal; we
just need to have the kind of discussion one would expect a new crypto
scheme proposal would engender.
BTW, here's a report of a zombie army of over 100,000 IPs attacking the
MX host of elvey.com:
http://www.emailaddresses.com/forum/showthread.php?postid=198568#post198568
*e.g. It's not about stack depth. Also:
"The reason I do not want to go down the csv path is that I have yet to
see a
clear and concise explanation of the proposal..."
If there is a there there it will be possible to state in a short post the
changes necesary to express csv semantics in spf syntax. "
MOVING FORWARD:
Here I try to flesh out further how an attack might (not) work.
1) It would make sense to assume the attacker will have most leaf nodes of the
SPF records it published be victim nodes, and that some non-leaf nodes could be
as well (e.g. include:msn.com)
If we make the (perhaps unwarranted) assumption that SPF checkers rely on local
caching DNS resolvers that hold the world's SPF records, then are we safe? No,
with a dynamic SPF record with thousands of leaf nodes, all random macros, no
DNS resolver can cache that. No scheme for determining that the domain or any
IPs involved can be blacklisted thereby has been presented or comes to mind.
What if we eliminate macros? Well, a)I don't think we should but b) does it
fix the problem?
Doug's attack scenario made no use of macros, and seems reasonable, so probably
the answer is 'no'.
However, let's take a step back. Before fetching the whole SPF record, the
domain will be checked with a reputation service.
Perhaps we say that the first N (N=3?) UDP DNS queries to fetch an SPF record must either fetch the whole record or specify a reputation service that at least gives the domain enough credibility for a fetch of the rest of the record to be warranted. Thoughts, anyone?
Perhaps simply the fact that the domain hasn't been blacklisted gives the domain enough credibility for a fetch of the record to be warranted. Thoughts, anyone?
A point that I thought was obvious, but some may have missed: if an SPF
record's tree can be ten levels deep, it can require thousands of DNS queries
to resove. The number of DNS queries is what needs to be controlled.
PS. I wrote this post before reading Greg's about limiting posts, which was probably deservedly targeted partly at me.
I'll bite my tongue for a while. <Err, just read Meng's post. I was convinced that if SPF doesn't act as an amplifier, it's fairly safe. Now I realize that even in that case, it still isn't safe. But neither is CSV. So why worry?> Sorry my posts (all to 2 threads) were excessive, and the thread that went downhill.