On Thu, 2004-09-23 at 00:15, Matthew Elvey wrote:
<snip>
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 would agree that someone making an effort could protect their DNS
servers, but the risks parsing script in DNS TXT records traipsing from
DNS server to DNS server does not compare to a single lookup of a binary
record.
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).
This is entering a new territory where DNS is used to authorize
transactions with a cost incentive to defeat these protections. Yes,
one could use carefully configured DNS servers to minimize this risk.
This should not overlook the fact this risk was not necessary however.
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:).
Using SPF records is not relevant to what is required of SPF?
If SPF was limited to CIDR notation and the MX record, then the value of
SPF would increase significantly as a white-listing tool. Much of the
label construction macros and exists syntax reduce SPF's value and will
likely serve to obfuscate a ploy that hides zombies.
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.
What you seem to miss is that SPF does not differentiate between
authorization and administration. There is no way to know the
relationship of a record in another domain. The cost of doing business
in this area is based in no small part on getting this right. I see no
reason to blur the distinction nor do I think the motive for using SPF
records for this purpose is well founded. If the MTA is not willing to
provide a significantly strong identifier, it does not make sense to
start guessing what is meant by the SPF records. The fall back would be
using the address. There can be no implied contract where a domain
becomes accountable for the actions of others trusted to send their
mail.
A provider lax in their security should not be allowed to hide behind
their customer's domains. Should the provider wish to force the
customer to accept this risk, they can ask to have the customer setup a
CSV-CSA record that enables their servers. You do not want this
accountability to be implied as you suggest.
[mailbox.dom] 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.
SPF requires the addresses of the entire mail channel. It is odd that
you would call that dumb.
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.
You have missed the point of the example. Attempting to use SPF records
for the dual purpose of creating an address list for the entire mail
channel versus an address list for just the MTA are not protected by way
of the label.
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!)
I said IN one of the ISPs. You are leaving your reputation exposed by
allowing the EHLO domain to reference an SPF record. A CSV-CSA record
has but one purpose and is of a much more limited scope.
<snip>
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.
I would hope it never comes to groping through various TXT script
records looking for a clue. I understand what you are attempting, but
there are risks getting this wrong. It is not worth the risk.
<snip>
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".
There are significant liabilities getting this wrong.
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!
But either label may appear within the EHLO response. You want a label
that can only be used for the single purpose of indicating the
administration of the MTA. From this information, it is a small matter
to establish the mailbox-domain/mail-channel association. The
mailbox-domain is too weak of an identifier for assessing reputations
however.
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.
Yes.
-Doug