Re: Why we should authenticate multiple identities

On Sat, 2004-09-18 at 11:24, Meng Weng Wong wrote:
> On Sat, Sep 18, 2004 at 07:01:14PM +0100, David Woodhouse wrote:
> | 
> | This is going to be _entirely_ counterproductive in the long run. If you
> | want true authentication, implement a true end-to-end scheme rather than
> | a hop-by-hop scheme which cannot ever solve the problem. MARID has its
> | place but this is _not_ it.
> | 
> 
> I plan to implement DomainKeys as soon as a plugin is
> available for my MTA.  Have you implemented it yet?

I suspect the ultimate solution for digital signatures will be a merger
of IIM and DomainKeys.  I'll wait to see how these solutions are
resolved once MASS gets going.

> | We need to stop disingenuously selling SPF/SenderID as a real
> | authentication scheme. Those who sell it like this are doing us _all_ a
> | disservice because they're going to severely hurt adoption of whatever
> | true authentication scheme is settled upon by those groups who are
> | working on it as we speak.
> | 
> | As for selling SPF as a method to stop bounces -- that's just bizarre.
> | BATV/SES are a totally effective way of doing that, without requiring
> | _anything_ of third parties for the 'publisher' to get the benefit.
> 
> I will try to clarify an important misunderstanding.
> 
> SPF Classic targets the practice of return-path spoofing.
> 
> The immediate benefit to publishers is that they will begin
> to get fewer bounces.
> 
> But that is not the only benefit.
> 
> The total benefit is that return-path spoofing will be
> reduced.
> 
> Part of the harm of return-path spoofing is that
> undeliverable addresses generate cause bogus bounces.

The reason for the spoofed MAIL FROM strategy is to circumvent
blacklists which prevent the message from being sent directly.  BATV
blocks this back-door technique entirely.  A public version of BATV
should also allow the return path to be discarded before an attempt to
send the bounce is made.  The message will be stopped before it is sent
in most case however, even with the private mode.   

> But another part of the harm of return-path spoofing is that
> deliverable addresses receive forgeries.  A bounce may not
> get generated, but harm is still done.

By preventing the success of this strategy with BATV, there should be
fewer such attempts over time.

> I agree that BATV/SES are the best solution to the
> stop-bogus-bounces problem, better than SPF Classic because
> they can be implemented unilaterally.  The cost is only
> slightly higher than SPF Classic: both require domains to
> corral all their users into using the domain's approved
> servers.  In addition, BATV/SES sign outbound return-paths.
> 
> However, BATV/SES only limit the harm from the fraction of
> the mail that does bounce.  It does not address the fraction
> of the mail that is delivered.  SPF Classic and Sender ID do.

BATV can be done by the MUA as well as the MTA.  There is not a
requirement to constrain where the message originates for the BATV
scheme to still function.  The granularity of the BATV can be over both
users and time.  Once implemented system wide, there will be a high
percentage of bounces eliminated.

SPF or Sender-ID schemes do not address the sources of abuse.  Abusers
can publish these records as well as legitimate domains.  As both the
SPF and Sender-ID identities are easily spoofed, these names are
worthless for asserting a reputation without the risk of harming
innocent domains.  Their weak identities likely make these schemes more
of a risk than an asset.  

> Therefore, the benefit of SPF Classic goes beyond reducing
> bounces.  Likewise, the purported benefit of Sender ID
> addresses phishing, which for whatever reason is not being
> addressed by true end-to-end methods today.

Sender-ID does not address phishing!  If anything a confidence artist
will likely use the "validations" of Sender-ID as a means to establish
credibility which can be done a number ways.  If financial institutions
adopt consistent EHLO names and have these validated names made visible,
this would make phishing significantly more difficult.  As it would be
difficult to spoof the EHLO name, it is not likely to serve to falsely
increase the credibility of a message.

Unlike Sender-ID, a consistent field would be made visible which
prevents the sneak path made possible by differences in the PRA
selection algorithm.  Until the MUA is upgraded to display this
validated EHLO name information, nothing changes with respect to the
level of reliance consumers are asked to give the mailbox addresses they
see.  In the case of Sender-ID, the PRA may be fully validated by the
MTA, but the From can remain Big-Bank.com.  Suggesting consumers can
trust the mailbox domain once Sender-ID is in place would be extremely
hazardous.  

> When banks start DomainKeys or S/MIME signing all outbound
> mail, I promise to give up SPF and Sender ID.  If you want
> me to stop campaigning for SPF and Sender ID, I suggest you
> focus your energies on the dependency.

Just like Sender-ID and SPF, these signatures will not reduce the spam
problem.  With the higher overhead needed to process these signatures,
it becomes even more urgent to address the spam issue for these
technologies to be viable. 

> To reiterate my position: if you believe you have the One
> True Solution, please go and help make it happen.  If you
> believe that someone else's One True Solution is wrong, it
> is more productive in the long run to work on your solution
> than attack somebody else's.

Focus on goals more than a specific solution.  It seems serious issues
are not addressed out of a sheer desire to promote "the" solution
irrespective of potential downsides.  As was illustrated by the
marid-mpr draft, taking two steps in the process actually takes less
time, incurs less cost in terms of maintenance, and protects the
customers of providers by not forcing a mailbox domain or allowing a
provider's neglect to unfairly tarnish their domain's reputation.

By the same token, responsible providers must be allowed to defend their
address space from abusive customers.  This is often done through
transparent interception or port blocking.  Devising a scheme that works
for an end-to-end exchange is not appropriate for mail that must
consider the use of a shared MTA.

-Doug