Re: Why we should authenticate multiple identities

On Sat, 2004-09-18 at 08:49, Meng Weng Wong wrote:
> A patent application is not a patent; I understand that
> nowadays applications are filed containing many claims that
> the filer doesn't actually expect to be approved, but if
> they are approved, bonus!  So let's look at which claims we
> can realistically expect to survive into patent form, and do
> our best to educate the patent office about the rest.  The
> ones that do make it into the patent may not turn out to be
> an encumbrance after all, or if they are an encumbrance at
> least we have a solid idea of how to route around them.
> 
> On Sat, Sep 18, 2004 at 12:34:13PM +0100, Roy Badami wrote:
> | 
> | I don't think that's true.  The domain/IP verification schemes
> | directly address forgery, in a way that CSV doesn't.  Think about
> | Sender ID as a tool for senders who (for whatever reason) want to be
> | able to prevent others from sending forged mail claiming to be from
> | them.
> 
> I agree that the anti-fraud aspects of SPF/Sender ID are
> stronger than CSV, and should not be abandoned just yet.

Just as Sender-ID required making the PRA visible, making the validated
MTA EHLO name visible would play the same role in preventing spoofing. 
To also aid those where the EHLO domain is different from that of the
RFC2822 From, a simple name list provides a means of association which
can be obtained within a single DNS lookup.  This makes SPF/Sender-ID
seem extremely clumsy for this purpose.

> CSV alone is not sufficient because it has a weaker
> deployment driver than SPF / Sender ID.  To wit:
> 
> Suppose we have lazy.example.com.  We want to encourage
> lazy.example.com to deploy whatever we come up with.  But
> they're lazy, so they naturally want to know the
> consequences of noncompliance.
> 
>     "If I don't publish CSV records, what have I got to lose?"

CSV would allow a low cost means of white-listing.  Rather than
obtaining hundreds of addresses that will need constant maintenance, the
root MTA name plays that role.  As I also illustrated with marid-mpr
draft, this also greatly reduces overhead needed to associate ANY
mailbox domain with the MTA.  CSV lays a solid foundation for more
advanced schemes like MPR later.

>     "Spammers might spoof with your HELO domain name."

Actually, I find BATV more compelling in preventing the MAIL FROM
spoofing than SPF.  That would remove some SPF motivations.  BATV
provides this protection unilaterally. 

>     "Will people reject my mail simply because I have no CSV
>     record?"

I would expect any reputation scheme to evolve into known good, or known
affiliations (verified by way of the CSV name), and have the unknown
receive slow path treatment and perhaps extensive filtering.  The
motivation would be to restore an ability to send higher volumes of
mail.  A reputation scheme can not be based upon the identities obtained
from either SPF or Sender-ID as these identities are far too weak.

>     "Considering that lots of MTAs don't even HELO with a
>     resolvable hostname, and we seem resigned to that, frankly
>     I'd have to say they're not going to reject your mail."

Until there is also a CSV-CSA record discovered, then the advantages of
being recognized will not exist.  CSV will allow the validation of the
MTA by name.  CSV is resolved to change the depreciation of the EHLO
name.

>     "Then why should I bother?"
> 
>     "Because it makes life easier for other people who'd be
>     victimized by spoofing --- we aim to get CSV records on
>     every legitimate HELO hostname in the world so we can
>     close that loophole."

Currently there is a tremendous expense consumed by those that send mail
using false identities.  This may mean a phase-in aimed at slowing this
flood of abusive mail.  To consume less time looking through filtered
mail, and to conserve the remaining network for productive uses, a
combination of white-listing and slow path approaches should provide
plenty of motivation.  The white-list may even allow an ability to
override an IP address black-list. 

> The SPF story goes like this:
> 
>     "If I don't publish SPF records, what have I got to lose?"
> 
>     "Spammers might spoof with your domain name in the
>     return-path or the headers."

But if the domain leaves the SPF/Sender-ID list open to allow the
acceptance of forwarded mail, then this will actually invite spoofing as
a means of usurping the domain's reputation. : (

>     "Will people reject my mail simply because I have no SPF
>     record?"
> 
>     "Considering that lots of domains have no SPF record,
>     that day is pretty far off.  Though you never know how
>     aggressive some people might get."
> 
>     "Then why should I bother?"
> 
>     "Because when people forge your domain name in the
>     return-path or the headers, you get the bounces, and
>     your users get phished.  Is that a problem for you?"

BATV solves the bounce mail problem.  SPF NEVER stops the phishing
problem.  Even Sender-ID would be a valuable tool for a confidence
artist, as it allows easy means to either spoof of deceive the
recipient.  Displaying a validated EHLO name would be a much more
difficult name to spoof and where financial institutions should make an
effort to be consistent in their use of these EHLO names.

Making the EHLO name visible when it is validate would also be
motivation for the deployment of CSV records.  Making this name visible
would also provide valuable consumer protections that are not possible
with SPF or Sender-ID.  In addition, the use of these names does not tie
consumers to a particular provider, nor will this name risk the
reputation of a domain that uses the services of providers.  CSV leaves
the accountability with the providers.

>     "Oh, then yes, that is a problem."
> 
> So it seems to me that the average domain owner has a more
> compelling case to do SPF than CSV.  I'm not saying nobody
> will do CSV: I fully expect ESPs and ISPs to do CSV on their
> MTAs, but you're not going to see uninterested parties
> putting negative CSV assertions on all the other hostnames
> that could be HELO'ed by MTAs.  By contrast, I expect many
> more people to put SPF records on their domains because the
> benefits are more immediate and more apparent.

The risks publishing SPF records will become more apparent when SPF
based reputation becomes employed.  Expect a flood of unhappy
individuals and litigation.  Should the validated EHLO domain become
visible to the recipient, then this acts to protect their name.  This
can be confirmed by way of a simple list if needed.  Why expend all the
effort listing addresses over and over?

> | As a tool for recipients, Sender ID and CSV both provide a hook on
> | which to hang reputation and accreditation systems, and I'm agnostic
> | as to which will work better in the real world, though my feeling is
> | that they may in fact turn out to be complementary.
> 
> I agree that they will be complementary.  In the same way
> that restaurants offer a variety of eating options to
> satisfy different needs, we should aim to offer a variety of
> authentication options to accommodate the market better.

Although I would agree that SPF plays a more significant function than
Sender-ID in combating spam, I suspect BATV remains a better solution in
that respect.  SPF or Sender-ID can not live up to the promise of
providing trustworthy validations of the sending domain.

> I have been observing a pattern of fallacious debate which
> can perhaps be called "winner takes all".  In this pattern,
> when you are given a choice of N options, you are allowed to
> pick only one: so proponents fight tooth and nail for their
> favourite choice.  This happens a lot because winning feels
> good; many of us are trained to try very hard to win; and
> besides, people who do not subscribe to this pattern of
> living tend to be interest themselves in things other than
> IETF working groups.

There is a large infrastructure built upon an incredibly ubiquitous
application.  Retaining the scalability of this application also means
considering the implications any scheme has upon routing and overhead. 
In my view, SPF and Sender-ID fail in those considerations.  Making a
cornucopia of options for what should be a universal method to send a
message is also counter to such a goal.   

> Very often, though, in the real world, we end up with a
> blend of multiple inputs, or we end up going with a
> plurality of the choices that lie before us.  Yesterday at
> lunch we ordered the chocolate catheke *and* the key lime pie.
> There's nothing inherently wrong with getting two desserts
> instead of one.  There are some operational considerations,
> of course: it costs more, and we certainly didn't want to
> order every single dessert on the menu just to have a taste.
> In the same way, we probably don't want to tell the Internet
> to have to do 512 different things; if we can limit our
> recommendations to a small set of four or five they'll
> probably find that livable.  Any reasonable person who hears
> "this is the one and only thing you have to do" will probably
> think was a bit of a hard sell.
> 
> The silly sort of "winner takes all" debate ends up looking
> like:
> 
>     "Children, what is your favourite colour?"
>     - "I like yellow!"
>     - "I like blue!"
>     - "No you don't!"
>     - "Yes I do!"
> 
> I am implementing a next-generation system based on the
> Aspen model of authentication, reputation, accreditation.
> In that system, I'll check authentication on SPFv1, SPFv2,
> CSV, and Domain Keys.  I'll check Spamhaus and Cloudmark
> Rating and the VDL.  Two heads are better than one, and
> yellow and blue go very nicely together.

Will you be providing the reputation services for SPF?

-Doug