ietf-mxcomp
[Top] [All Lists]

Re: Make CSV backwards compatible with legacy SPF records?

2004-09-23 00:15:23

Aha! I found the post with the relevant stats. They're from March, though. Also, my recollection was off - domains using the ten most popular SPF records included only 1/2 of the total domains with records. http://www.imc.org/ietf-mxcomp/mail-archive/msg00644.html Something reasonably recent would be great.

Anyway, let's consider the top ten (which I've reordered a bit) from wayne:

1 1097 v=spf1 mx -all 3 463 v=spf1 a mx ptr -all 4 429 v=spf1 a mx -all 9 131 v=spf1 a mx ?all 6 306 v=spf1 a -all The above would generally take 1-3 UDP DNS queries to resolve. 5 325 v=spf1 -all 7 171 v=spf1 +exists:CL.%{i}.FR.%{s}.HE.%{h}.null.spf.example.com -all 8 131 v=spf1 include:example.org ~all 10 130 v=spf1 ?all These are equivalent to the null set, for the purposes of my proposal.

2 804 v=spf1 ip4:a.b.c.d/32 ip4:a.b.c.d/32 a ptr mx -all This is probably no longer in the top ten.

On 9/22/2004 8:44 PM, Douglas Otis sent forth electrons to convey:

On Wed, 2004-09-22 at 17:16, Matthew Elvey wrote:

Huh? The question is about the record given, which has none of these problems. ( foo.dom. IN TXT "v=spf1 mx -all" )


There is a good overview here.
http://www.securityfocus.com/guest/17905
Yes, a good refresher. Anyway it leads me to believe that the record only suffers from a problem that also afflicts CSV and that a good bind9 or djbdns config can handle.

I conclude from your statement that given the proposed record, foo.com would be pretty safe from being blacklisted by an SPF reputation service. I don't see a specific example of what would lead a reputation service to blacklist foo.dom that could not befall a CSV system. Do you claim a server running CSV (and not using DNSSEC, of course) is not vulnerable to a poisoned cache?

By limiting the mechanism to a single DNS lookup to a single DNS server,
the exposure is much less.
Ok, it is a little less. The risk is also low to start with. (Birthday attacks aren't common, AFAIK; I've never logged one.) It's even lower to nonexistent given recent/patched/secure DNS software and systems (e.g. a split-split configuration).

For what it is worth, SPF "requires" more than a single record be read
perhaps from many different DNS servers.  This opens a sizable can of
worms.
Clearly, I need to better explain my scheme, as it still seems unclear to you that what SPF "requires" isn't relevant to my proposal! Please, can you give up using this as an opportunity to bash SPF? It's OT. (Note the changed Subject:).


As I said in private email, I'm trying to nail down as mainstream an example as possible. I can't think of one, given this record.

Given a record *without* -all, or with entries like ?comcast.net, I can see how a domain could well get blacklisted.

Few large organizations would wish to deal with the results of full
fledged SPF and closed records.
Doesn't matter; assuming this is true, it doesn't hurt my proposal.


<snip>
The label used to select the SPF record is normally based upon the
mailbox domain to select a full set of outbound MTAs.  The EHLO name can
be made to match any such mailbox domain provided one of the machines is
permitted in this SPF record set.  This would be bad.
I asked for an example. I see no example here. I can't extrapolate from what you have said to come up with an example, either.
Perhaps you're avoiding providing one.

Example: Mailbox.tld has SPF records that define the entire address
space for three of their providers where they outsource some of their
mail, and their own.  I contend reputation should be based upon what you
have control over.  That would mean it would not be to your advantage to
include the machines of these other providers in a reputation
assessment.
Ah, I did say ip4 (and therefore CIDR ranges) might be OK.
(I did suggest subsequently in mail to John Leslie that perhaps just +ip4:a.b.c.d/32 might be OK, note the /32!)
Perhaps even that isn't a good idea, as

mailbox.dom spf   ip4:[isp1's smtp]/32,ip4:[isp2's smtp]/32,ip4:[isp3's smtp] 
-all

enables me to inappropriately stake my domain's reputation on the ability of ISPs 1-3 to keep their smtp servers from being used to spam. HOWEVER: It's already the case that such SPF records are inappropriate. If I don't have high confidence in the ISPs, then the appropriate record would be:

mailbox.dom spf   ?ip4:[isp1's smtp]/32, ?ip4:[isp2's smtp]/32, ?ip4:[isp3's 
smtp] -all
and this record would be equivalent to the null set in my scheme: my proposal 
ignores ~anything and ?anything.
Similarly, anyone creating a record like
mailbox.dom spf cidr isp1, cidr isp2, cidr isp3, cidr for self.
will suffer the consequences of doing something so dumb, if one of the 3 ISPs seriously fails keep their smtp servers from being used to spam using mailbox.dom. The domain will get blacklisted (in other words, its reputation will fall), and the spoofing will stop.
Of course, your other example:

ehlo.dom spf cidr for self
may also lead to a poor reputation - someone in marketing might decide to send a bunch of spam, get zombie-infected, etc., etc. So CSV-tied reputations won't be perfect either; it isn't reasonable to expect them to be. They just need to be reasonably secure.

A compromised host in one of the ISPs or even perhaps some clever shell
program issues EHLO with mailbox.dom rather than the intended ehlo.dom.

Sorry, how is a clever shell program not in one of the ISPs going to get away with this? (No BGP hack/bogon/break into mailbox.dom's server scenarios, please!)

<snip>
One, you want to use existing SPF records that were not intended to
provide the narrow selection of machines administered by the MTA
operators.  Two, there is no means to restrict this list after the fact.
1) Sort of. 2) Nonsense. We ignore records or record components that don't meet our rules. Would you argue that there is no means to restrict a CSV "Client SMTP Authorization SRV Record" from having illegal values (e.g. a Weight of 8)?

The rules that accept only closed SPF components still do not achieve a
goal of assessing only the administrator accountable.
The rules I am refining do achieve that goal. Arguably, they do so better than CSV, because they'll work for most domains that haven't bothered to set up a CSV record. Heck, using the SPF 'best guess' may be appropriate where there's no SPF or CSV record - the A&R system will reflect reality if this guess allows much spam through.

<snip>
Your approach was to prune the record set used just for the EHLO
domain.
I don't think so. It's not clear what you mean by that, so I'm not sure, but your sentence doesn't make sense to me; I don't know what you're trying to say.

Just removing open elements will not achieve the desired goal as it does
not provide the same set.
That's not a logical argument. The ultimate desired goal is to address the spam problem. It may or may not be material to achievement of that goal to get "the same set".
That pruning can not differentiate between machines within a
delegated domain or machines within the administered domain. This would
be bad.
I don't see where I'm saying something from which one could conclude that a record for aol.com would be non-differentiable from one for dhcp234.234.dialup.aol.com.

SPF does not have the concept of administrative versus authorized. There is nothing in the syntax that would allow the differentiation. In
addition, the EHLO name can express any label to select any record.
a record for aol.com is still differentiable from one for dhcp234.234.dialup.aol.com!


I have not not suggested a scheme that would readily allow other domains to spoof the EHLO identity.

I even asked you to provide an example disproving this and you were unable to.

The line from Cool Hand Luke comes to mind.  It is not because I have
not tried.
You hadn't provided an example. Now you have. Though I don't think it disproves this, as I argued above. The example has enabled us to better discuss specifics.

<Prev in Thread] Current Thread [Next in Thread>