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

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. 

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.  It is
not clear how the domain owner will recover reliable use of their email
domain after publishing SPF and then being exploited.

This is a very real concern being completely ignored by providers
anxious to rid themselves of their responsibilities with respect to this
menacing abuse.  Nevertheless, abating abuse requires holding
administrators accountable and ensuring they stay on top of security,
access, and operational issues.  A reputation scheme MUST identify the
source of abuse, and not the "assumed" source of abuse.  A reputation
scheme must hold those responsible, accountable.  SPF fails badly on
both of these issues.  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.


> > 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.  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.  If their relay
provider was lax at security or preventing abuse, the domain owner can
seek a different provider to rectify any resulting problems.

You should put yourself into your customer's position.  Proclamations
that with SPF, some domain can not be forged are specious.  This of
course assumes closed-ended list, where the domain owner maintains
exclusive access to their servers.  Closed-ended lists are not
practical, nor do most domain owners manage their own MTAs with
exclusive access. 

A domain owner that protects the private portion of their signature,
does not depend upon an email provider to protect their reputation.
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?

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.
The provider could also offer to relay messages already signed by their
customers as well.  Either of these scenarios would be fair.

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.


> > 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.  The sender does not know what the recipient
uses to base their reputation assessments.  Someone can get seriously
hurt heedlessly publishing SPF.


> 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.  SPF requires assumed checks that may or may not
be performed.  In fact, some of these checks may require a license. : (

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.


> > 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.

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, filtering often employs a practice of
placing uncertain results into a junk folder.  With SPF, there are many
shades of gray. : (

> > 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.  Server authorization is far
too weak to base a presumption of having authenticated the sender.
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.


> 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.  ; )


> 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.


> 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?  Are you large
enough to make your claims a serious concern?  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?



> > 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. 


> > 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. 


-Doug