ietf-mxcomp
[Top] [All Lists]

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

2005-05-27 05:43:13



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
terry(_at_)greatgulfhomes(_dot_)com
Associate Director Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
Fax: (416) 441-9085