Re: draft-schlitt-spf-classic-01.txt

Douglas Otis wrote:
> On Thu, 2005-05-26 at 23:18 +0200, Julian Mehnle wrote: 
> 
>>Douglas Otis wrote:
>>
>>
>>>The email provider must be held accountable in any meaningful approach
>>>for abating abuse.  However, SPF avoids such accountability.  A provider
>>>may feel SPF based reputation systems are of little concern to them, but
>>>it should be of tremendous concern for their customers, who are often
>>>little more than domain owners.
>>
>>Why do you think ISPs must be held accountable instead of domain owners?
> 
> 
> Abating abuse requires diligence.  This diligence involves the
> monitoring of servers.  To protect the privacy of other customers, much
> of an MTA server's operation remains hidden from the domain owner, who
> is often just one of many typical customers.  With SPF reliance on the
> mailbox-domain, the server's administrator remains anonymous.  Negligent
> server operation will not directly impact the administrator, but instead
> impacts the domain owner.  A reputation system should hold accountable
> those who are expected to maintain diligence in respect to security,
> access, and operation.  Holding an innocent, feckless party accountable
> is simply an unfair practice.  Dare I say even foolish?
> 
> By the time a domain owner is made aware that volumes of abuse has
> emerged from some SPF authorized server, forging their mailbox-domain in
> some unexpected header, the reputation of their domain may have become
> unsuitable for email.  The means to recoup their reputation in this
> situation may not be practical. 

Interesting so if SPF fails then SPF will fail.

I say this because the only way the domain owners reputation could have 
gotten tarnished was if either:
1)  they did not implement SPF to protect forgery of their domain
OR
2)  they did implement SPF, and it failed to protect the forgery of 
their domain

SPF cannot be help responsible for #1

#1 can only happen if SPF doesn't work, but if SPF doesn't work then all 
this is moot.

Perhaps Doug, you are not talking about SPF, because "some unexpected 
header" sounds an awful lot like you are referring to the la-la 
dreamland that is PRA.

And SPF is *not* PRA.  Please don't confused between PRA and SPF (no 
matter what Meng has on the damn pobox website).


> 
> The domain owner may be innocent.  They may also view their domain as
> highly valuable.  They may also be required to seek expensive legal
> avenues to uncover the cause of their dilemma.  With SPF building upon a
> filtering paradigm, there may be no outward indication their messages
> are being silently dropped or placed into junk folders either.  

*sigh*

PRA may do silent dropping of email after acceptance..

SPF does MTA time rejection, so the sending MTA *must* know that the 
email was undeliverable, which guarantees all real, legit connecting 
MTA's get a clear rejection on the delivery status.

SA is the only major filtering that uses SPF after the fact, and even a 
FAIL scores less then 1 (0.8 something by default) and SA recommends not 
rejecting emails that score less than 5-10, then SPF unto itself cannot 
be what caused the rejection after acceptance.  Something else scored 
the other 4-9 points that were need to cause the email to be rejected by SA!

So don't say SPF causes silent dropping of email, its simply not true. 
Certainly not in the recommended use of SPF (MTA time rejection) and not 
even in the common not recommended use of SPF (SA).

> It is
> not clear how the domain owner will recover reliable use of their email
> domain after publishing SPF and then being exploited.

Domain owners can be exploited if they don't publish SPF, nothing 
changes by publishing SPF except, if SPF really does work (as time has 
shown once forwarders are fixed), SPF may prevent forgery that is the 
exploitation that could have resulted in bad reputation.

> 
> This is a very real concern being completely ignored by providers
> anxious to rid themselves of their responsibilities with respect to this
> menacing abuse.  

SPF is not ignoring concerns.  The concerns you have stated are either 
unfounded or apply to PRA, not SPF.

> Nevertheless, abating abuse requires holding
> administrators accountable and ensuring they stay on top of security,
> access, and operational issues.  

Are you suggesting every MTA operator review all inbound email for 
forgery/spam/viruses and do something with the ones that are bad?  Glad 
I am not paying that bill.

> A reputation scheme MUST identify the
> source of abuse, and not the "assumed" source of abuse.  

SPF is not a reputation scheme.

SPF is a means to make reputation schemes accurate by preventing forgery.

> A reputation
> scheme must hold those responsible, accountable.  SPF fails badly on
> both of these issues.  

No, it doesn't.  A reputation scheme allows domains to obtain 
credibility (or not) based on what the domain has done in the past.

SPF simply improves the ability for reputation schemes to be accurate by 
preventing forgeries from affecting the reputation database.

> It is folly to think SPF will improve the
> integrity of email or diminish the rate of abuse.  A reputation scheme
> based upon SPF authorization is certain to dramatically reduce email's
> integrity for the majority of domain owners.

I would love to see your facts, or testing, to justify this statement. 
Sounds like FUD.

> 
> 
> 
>>>Only signatures offer domain owners a modicum of control and oversight in
>>>their pursuit of protecting their domain's reputation.
>>
>>Why?
> 
> 
> By retaining a signature operation within their administrative control,
> the domain owner would have far greater control over the fate of their
> domain's reputation.  

Smells like you want to sell domain owners (or their ISP/MSP) something. 
  A certificate perhaps?  At least now I know your motivation for 
attacking SPF.

> They could utilize the services of an email
> provider to relay email from a dynamic location, without fear other
> abusive messages may be confused as being from them.  

Thank you for endorsing the use of SPF (because that is what SPF does, 
only without the need for MUA upgrades to check signatures, and no need 
for buying certificates).

> If their relay
> provider was lax at security or preventing abuse, the domain owner can
> seek a different provider to rectify any resulting problems.

Which is a good idea no matter what security protocols one implements 
(or not) for their domain.  Hence, thanks for the advice (albeit off 
topic or not specific to SPF).

> 
> You should put yourself into your customer's position.  Proclamations
> that with SPF, some domain can not be forged are specious.

Only when receiving MTA's don't implement SPF (or some other form of 
domain anti-forgery technique).  But those MTA's don't matter because 
they won't bother to implement submission of forged emails to domain 
based reputation lists (or would be irresponsible if they did).

>  This of
> course assumes closed-ended list, where the domain owner maintains
> exclusive access to their servers.  

Please explain, because I don't understand how you could possibly think 
that (recall the include and redirect mechanisms).

It does require that if they relay through their ISP's mail server(s) 
that their ISP publishes SPF, but how is that unreasonable?  (No domain 
authentication/authorization scheme can work 100% unless it has 100% 
deployment, and cannot be held responsible for not working where it is 
not deployed)


> Closed-ended lists are not
> practical, nor do most domain owners manage their own MTAs with
> exclusive access. 

Ah, so now you are talking about cross customer forgery within the same 
ISP.  Well, either your ISP has to implement protocols to stop cross 
customer forgery (or be proactive about dealing with it, but I don't buy 
that)  or we have, let's see, WE HAVE THE MESS WE ARE IN TODAY.

But bottom line, the majority of forgery I doubt very much comes from 
the same ISP as the domain owner.  (That's my experience from my log 
files, its someone else, often over seas, faking to be a user from my 
domain to see if I foolishly whitelisted by own domain name).

> 
> A domain owner that protects the private portion of their signature,
> does not depend upon an email provider to protect their reputation.

Unless of course, there are other people in the world how have not 
implemented signature protection.  Hmm, where have I heard before there 
could be failures if a protocol doesn't have 100% deployment?

> Especially an email provider with dubious motives asking them to publish
> SPF records.  How on Earth can publishing an SPF record be in the
> interest of the domain owner, after Microsoft proclaims server
> authorization is the same as sender authentication?

If you see the folly of what Microsoft is trying to do to use SPF 
records in ways not intended, GREAT!  But that is not fault of SPF.

No matter what they did, the police could not stop my neighbour from 
drinking and driving.  Even when they impounded his car he then stole a 
neighbours car.  Does this mean that to solve the problem the police 
should take cars away from everyone?  No.  They put the guy in jail 
because HE was the one that did wrong.

And SPF should not be discouraged because MS is abusing it.  MS should 
be stopped from abusing it.

> 
> A DomainKeys signature associated with the Sender header allows the
> provider to accept accountability for their customers, without mandating
> their customers change their email addresses or publish DNS records.

That's a great idea.  Let me know when there is a free version of 
DomainKeys.  And it works with mailing lists.  And it doesn't "violate 
the anonymity" of email (not that I believe that email should be 
anonymous, but that's one of the big whines I hear against correcting 
forwarding).

> The provider could also offer to relay messages already signed by their
> customers as well.  Either of these scenarios would be fair.

But not free.

> 
> With prior knowledge of the sender, perhaps in the case where an SPF
> record is being used to establish a white-list, SPF could offer utility.
> White-listing may be practical for typical bulk emailers, but not for
> the majority of email domains.  However, DomainKeys could supplant
> reliance upon white-listing, without the overhead needed to maintain a
> complex database that may create problematic overlaps.

I hear the words but I just don't see the weight of the arguments.

> 
> 
> 
>>>1.  Introduction
>>>
>>>[...]
>>>Unless providers can assure their customers that there are no conflicts
>>>within all message PRAs, any other customer would be allowed to create
>>>serious harm.
>>
>>If you are talking of cross-user forgery, see SPF, section 10.4[1].  This 
>>isn't something that can generally be solved by an authorization protocol 
>>that works with a granularity of IP addresses.
> 
> 
> You misunderstood the concern.  An email provider likely handles
> customers using many different mailbox-domains.  Yes, there could be
> cross-user forgery within a domain, but that was not the concern.  There
> could also be cross-domain forgery.  The provider is expected to make
> assurances that some range of domains is permitted specifically for
> those provided access to the MTA.  If the provider does not properly
> authenticate the user (some still exchange passwords in the clear), or
> does not evaluate the PRA, the domain owner is placed at risk by
> publishing SPF records.  

Uh, NO.  SPF records should not be used to evaluate the PRA.

> The sender does not know what the recipient
> uses to base their reputation assessments.  Someone can get seriously
> hurt heedlessly publishing SPF.

They do for receivers that correctly implement protocols (e.g. do not 
use SPF records for PRA).

Someone could get seriously hurt if other protocols like TCP keepalives 
are not properly implemented.  That doesn't mean we shouldn't use TCP. 
(repeat my drunk driving lecture here).

> 
> 
> 
>>If you are talking of something else, I don't know what it is.
>>
>>
>>>This harm could originate from a Zombied computer of such a customer.
>>>The abuser may utilize SPF records to obfuscate where the message
>>>originates to prolong their success, when seeing such messages are not
>>>blocked by the sending server.
>>
>>How could SPF records be used to "obfuscate" a message's origin?  The last 
>>time I looked, SPF didn't suppress the generation of "Received:" headers.
> 
> 
> Anyone that utilizes a large provider and publishes an SPF record that,
> in effect, proclaims such use, could enable an abuser to send from the
> correct server, while still lying about who they are.  SPF does not
> prevent this problem.  

Neither does domain keys, until of course the ISP/MSP upgrades the MTA 
to prevent cross customer forgery.  Once that is done, then EITHER 
method works.  Amazing, if everything is done then everything works, and 
if only some things are done then only some things work.  Fascinating.

> SPF requires assumed checks that may or may not
> be performed.  In fact, some of these checks may require a license. : (

Huh?

> 
> The abuser may wish to play this game until they have scorched the
> reputation of that domain, before usurping the identity of the next
> available victim, all while thanking SPF for making their fun possible.

Ditto for any forgery method that can be circumvented.  Including 
domainkeys.

> 
> 
> 
>>>SPF based reputation systems could employ local or divergent databases
>>>that attribute domain abuse based upon the "assumed" sender.
>>
>>So what?  Receivers are already doing the same with IP address white- and 
>>black-lists.  The world has not gone up in flames, though.
> 
> 
> Quite typically, providers that employ a black-hole listing service,
> will indicate the website of this service in the error message returned
> in the session refusal.  The person sending the message can opt to
> immediately try a different provider to send their message.  They may
> also elect to complain to the black-hole listing service that indicated
> the MTA they utilized is not properly administered.

Email that fails authorization/authentication do not get 
checked/submitted to lists BECAUSE they have failed.  Its only if the 
email passes that you then check the domain against lists.

> 
> Perhaps the server administration permitted access to the wrong person,
> perhaps they accidentally enabled an open-proxy in their network,
> perhaps they even allowed an open-relay.  Whatever the problem, the
> sender often knows where to go for restitution.  As SPF is intended to
> assist the filtering of messages

NO NO NO.  It is to be used for MTA time rejection, not post acceptance 
filtering.  And SA uses it for post acceptance filtering, but SPF unto 
itself will not cause the email to be rejected due to the incredibly low 
score a FAIL is assigned.

> , filtering often employs a practice of
> placing uncertain results into a junk folder.  With SPF, there are many
> shades of gray. : (

SPF is *not* PRA.  Please stop the FUD.

> 
> 
>>>How can the domain owner restore the use of their domain, after their
>>>provider naively believes they can assume how a record will be
>>>interpreted which has an undefined scope?
>>
>>(I assume you aren't implying that the concepts of accountability and 
>>reputation are fundamentally flawed.)
> 
> 
> The assumption that a mailbox-domain can be authenticated without the
> use of a signature is fundamentally flawed.  

In your opinion, especially if your opinion is to sell domainkeys.  The 
only thing that could be considered "flawed" is that it disallows 
anonymous forwarding without implementing some other forwarding method 
(such as SRS, SES).

> Server authorization is far
> too weak to base a presumption of having authenticated the sender.

Your argument does not hold even a drop of substance against the 
HELO/EHLO name checking of SPF.

And it doesn't hold any credence if one (like I) don't believe in 
anonymous forwarding.

> Server authorization in the manner of SPF also wrecks havoc on email's
> architecture.  There is no reason for this, when signatures require less
> effort and create less collateral damage.

But signatures cost more money, requires MTA's everywhere to upgrade 
(even those that don't WANT to participate), how is that not collateral 
damage?

> 
> 
> 
>>There are no SPF records with an undefined scope.  If, for v=spf1 records, 
>>receivers choose to apply Sender-ID's inconsistent scope definition (PRA) 
>>over that of SPF itself, is it SPF's fault?
> 
> 
> So are you going to tell a 900 pound gorilla they are wrong?  In the
> end, the gorilla will have their way with you.  ; )

The Open source community is a 1000 pound gorilla, once it aligns its 
forces.  Just because some big powerful idiot is king, does not mean the 
kings way is right.  Look through the history books, its what mutiny and 
revolution are all about.

> 
> 
> 
>>Have you complained already to Microsoft and the IESG about Sender-ID 
>>redefining v=spf1 records?  If not, why do you keep bringing up this issue 
>>here?  To say that even though this inconsistency is not SPF's fault, 
>>another draft can always be employed to destroy its usefulness?
> 
> 
> Strange, I see the same author on both drafts?  Who's fault is that?
> Depreciate the use v=spf1 to be assured of avoiding this serious
> conflict.

Cute.  Why can't you just deploy DomainKeys, and let the best product 
win.  Why must you resolve to attack SPF?  Are you that fearful that SPF 
will succeed in the end that you feel a need to attack it to try to get 
DomainKeys deployment to catch up?

> 
> 
> 
>>What if I submitted a draft to the IETF that conflicted with the DomainKeys 
>>specification?  Would that make DomainKeys useless (or harmful)?
> 
> 
> What patent licensing restrictions would you impose?  

Nothing valid.  But who said the MS patent crap is valid?  Its not even 
issued yet, just applied for.

> Are you large
> enough to make your claims a serious concern?  

You don't need to be large to apply for a patent.  But your missing the 
point, the point was if someone applied for a patent that conflicted 
with domainkeys, does that make domainkeys bad?  I think not.

> Would you be asking
> domain owners to fall into a trap, which over time as a ubiquitous
> reputation program is applied, necessitates domain owners find providers
> that license your scheme?

Um, that sounds like PRA, not SPF.  Nothing like SPF at all in fact. 
Interesting though, I wonder if it sounds like domainkeys?

> 
> 
> 
> 
>>>10.  Security Considerations
>>>
>>>[...]
>>>With this draft mandating more than one hundred DNS lookups,
>>
>>The SPF specification does not "mandate more than one hundred" DNS lookups.  
>>It mandates that a receiver must be prepared to perform at most 111 DNS 
>>lookups.  This does not mean that the usual case is anywhere near that.
> 
> 
> Odd, but I see a required minimum as a mandate, and 111 is more than
> 100.  If there are on average 5 queries created for every lookup, this
> could mean 555 queries are required to resolve a server's authorization
> for a single message. 

Which would be cached.  And the boundary case is likely only reached on 
those trying to spam or do a DOS attack.  But spammers don't win, 
because their email is still delayed.  And DOS attackers, well dealing 
with DOS is a fact of life no matter WHAT protocols one implements.

> 
> 
> 
>>>this raises a concern regarding how the 20 second time limit is employed.
>>>A local recursive DNS resolver may act as a UDP amplifier.  Congestion
>>>avoidance depends upon the application making the requests to wait, in
>>>order to maintain stability.
>>>[...]
>>
>>This sounds like a valid concern.
>>
>>
>>>There should also be a warning about acceptance of duplicate records.
>>
>>What do you mean by "duplicate records"?
> 
> 
> DNS transactions are only protected by a 16 bit integer.  Often routines
> utilize the UDP port to multiplex results.  The sequence of Domain Name
> Server queries dictated by an SPF script may expose the port being used.
> There is also a further risk that replicate queries, as possible with
> Bind 8 for example, may again greatly increase the chances of guessing a
> transaction.  As this can be caused to happen repeatedly, success does
> not need to be 100% for this to be a concern.  The two-tier
> recursive/non-recursive resolver was suggested as a defensive measure.
> It just seems more informative than recommending DNS paranoia. 
> 

Agreed.  IF one is using a DNS service with known vulnerabilities and IF 
this and IF that THEN, well, you deserve to be vulnerable, don't you?


Terry

> 
> -Doug
>     
> 

-- 
Terry Fielder
[email protected]
Associate Director Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
Fax: (416) 441-9085