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

On Fri, 2005-06-03 at 12:47 -0400, Alan DeKok wrote:
> Douglas Otis <[email protected]> wrote:
> > IP address space pressures has caused much of the sharing of IP
> > addresses for both MTAs and Web servers.
> 
>   What's up with 29/8 & 30/8?  There are 50M addresses unused.

IP address conservation has slowed the rate of consumption.  Once these
addresses are fully assigned, reliance upon IPv6 becomes required.  As
with many things, preparation requires time to phase-in full support.
In the meantime, to allow communities early in their Internet deployment
a reasonable number of IP addresses, some addresses need to be reserved.
If each domain name required a unique address, this reserve would be
quickly exhausted.

> >  One reason to deploy a name based reputation system, is to overcome
> > the problem of IP address aggregation affecting so many different
> > domains.  The application of reputation makes domain/user isolation
> > critical for the domain owner.
> 
>   In the absence of DNSSec, using DNS names for reputation is a bit
> problematic.  You're never completely sure that the domain is
> currently being controlled by it's owner.

DKIM creates far fewer DNS security concerns compared to SPF which
reduces some of these potential DNS problems, rather than adding to it.
For reasons actually unrelated to DNS, DNSsec should be deployed.  While
even DNSsec will not prevent every attack vector, it will expose more
attack efforts.  Hopefully, diligence and cooperation prevail in
cutting-off network providers that permit the coordination such
activities.

There is a need to establish a re-assignable ID number to identify those
that trade or use stolen identifiers.  By requiring a timestamped query
to a clearinghouse, to return to the requester a relevant static index
(pseudo SSN), would make this information far more risky for the
criminals.  The query may also identify abuse attempts.  There could be
many re-assignable ID clearinghouses used for various purposes.  


> > Once an MTA administrator buys the notion that SPF/Sender-ID takes care
> > of abuse, where reputation no longer affects them directly, they have
> > less incentive to do the real job of abating abuse before it is sent.
> 
>   I'm not sure there's any technical solution to that problem.

The simple technical solution would be to _always_ base reputation
accrual upon "Authenticated Senders" and _never_ "Server Authorization."
Going down the list of identifies available that could isolate security
and abuse issues to the accountable administrator, it would be:
  - IP Address
  - Authenticated HELO Name
  - Validated Signatures

You will notice that the mailbox-domain is not in this list.  This
mailbox-domain identity is passed from MTA to MTA, and is unrelated to
an accountable administrator.  SPF or Sender-ID also makes a false
assumption that the MTA is not shared, or that the MTA administrator
ensures user/mailbox-domain relationships are protected.

I have yet to hear anyone caution domain-owners they should first become
indemnified in their provider's SLA, and be assured only their messages
are permitted to use their domain in the bounce-address or the Purported
Responsible Addresses, as defined in Microsoft's proprietary algorithm.
The penalties should be sufficient to cover loss of the use of the
domain.  This SLA should provide a means to verify any allegations of
negligence on the part of the provider.  Without this agreement, the
domain owner would be placing their domain's reputation in extreme
peril.

-Doug