spf-discuss
[Top] [All Lists]

Re: Re: Extreme times call for extreme measures?

2004-10-07 00:15:57

On Thu, 7 Oct 2004, Meng Weng Wong wrote:

I think one possible optimization there is for ISPs to agree
on a convention for publishing DUL data in SPF format, which
RBLs can then suck down automatically.

For example, broadband.net could publish

  _dul.broadband.net IN TXT "batch spf2.0/ptr -ip4:192.0.2.0/24 
-ip4:192.0.3.0/24 ..."

BAD BAD BAD IDEA - see major security problem described below
 
And an RBL system would probe for _dul.*.{com,net} etc and

Are we back again at the point of deciding that we can find deligated
domain of the company by looking at its full domain? Not easily possible.

As for optimization - remember that DUL is one dns lookup. SPF for PTR is
also one dns lookup, so I'm sorry but there is no need for optimization
if all ISPs actually enter SPF data for PTRs (which I admit is somewhat
unlikely in near-term). The only place where optimization is needed is
helping to enter spf records for all those reverse dns names, but script
can be created (in fact I'll write it up) for large number of zones.

automatically build its DUL from the resulting entries.  Of
course you have to be careful about cross-domain poisoning
(_dul.badguy.com could list -ip4:0.0.0.0/8) 

Its not just "-ip4:0.0.0/0/8", this is a MAJOR SECURITY PROBLEM, you cant
rely on building blacklist based on multiple sources where each source
may not be trusted - and any ISP particpating can any other ISP's ip
address and blacklist that ISP's mail server or clients. This is just
waiting to be abused. 

but sanity checks shouldn't be hard.

Actually they are. You have to specifically limit what can be entered to 
only ip addresses assigned to that ISP. This requires manual updates 
(including necessary whois lookup) between ISP and DUL operator to adjust 
a filter whenever ISP gets new ip block.

This setup will never fly with any serious ip security engineer and you 
can be certain all big ISPs have them, nor would it ever be allowed to 
come through IETF to become even experimental RFC.

-- 
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net