ietf-mxcomp
[Top] [All Lists]

Why we should authenticate multiple identities

2004-09-18 08:49:30

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.

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?"

    "Spammers might spoof with your HELO domain name."

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

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

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

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

    "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?"

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

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

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.

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