Re: Make CSV backwards compatible with legacy SPF records?

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