spf-discuss
[Top] [All Lists]

The path to a PKI architecture

2004-01-13 07:35:07
On Wed, Jan 14, 2004 at 01:01:41AM +1100, Chris Drake wrote:
| 
| As a PKI-aware person, do you know if anyone is doing any anti-spam
| PKI work, like any paid-for "I am not a spammer" certificate system or
| other PKI-based anti-spam solutions?  I think this would be an ideal
| alternative to SPF, since it gives SENDERS a way to ensure their
| emails reach their recipients - and the rights of senders are getting
| totally lost in todays anti-spam frenzy.

You can always do

  "v=spf1 smime -all"

I've seen a few .sigs that read like "All mail signed by S/MIME".
The above SPF record is merely a formalized way of making the assertion.

SPF is a sender authentication framework.  The specification for the
framework also happens to describe a designated sender scheme because
it's the easiest and most convenient for the vast majority of people.
SPF can also describe other sender authentication mechanisms (eg.  Yahoo
DomainKeys) which put a cryptographic signature in the message headers
or body, and if the world wants to move in that direction I have no
problem with that.  The tradeoffs are that a cryptographic scheme would
require the download of the message body and a computationally expensive
analysis, which costs bandwidth and CPU.  ISPs don't want to pay that
price if they can help it.

If a designated sender scheme is effective at discouraging spammers, we
may be able to move on to a crypto scheme.  Spammers want their messages
read, but ISPs want their costs to go down, so we would need widespread
implementation for it to work effectively.

The main objection to signature schemes is this: today, most mail
clients don't have any kind of crypto plugin.  That means that if mail
is to be signed, it has to be signed by a central gatewaying MTA.  If
it's going through a central MTA, we might as well identify that gateway
by IP address.  That way people don't all have to upgrade their MTA to
gain the benefits of sender authentication.

When, one day, crypto is built into all mail clients, then the original
dream of PGP will be realized, and we don't need the centralized servers
anymore, and instead of "v=spf1 mx" we can declare "v=spf1 pgp".  But
this relies on a technological shift which hasn't happened yet.

When the primary sender authentication mechanism is crypto rather than
IP based, you open the door to bluffing games: a spammer will try to
send a message, claiming it is signed, to a skeptical recipient.  The
skeptical recipient will say, "ok, your domain declares smime, so I'll
take the risk of downloading it".  The spammer says "it doesn't really
have a signature, so I'll take the risk that it might be deleted".  This
is an artefact of the SMTP design where message data is passed all at
once.  A future extension to SMTP could put the signature not in the
message headers or body but in the envelope itself: for something along
these lines, see
http://www.ietf.org/proceedings/01mar/I-D/msgtrk-smtpext-00.txt

We can't move straight to the PKI phase because it has an energy cost:
you have to upgrade all the MTAs everywhere to support ENVID relaying
and so on.  SPF has a lower energy barrier.  People will use that first,
and if it works and we can take a break from fighting the antispam
fires, we can then move on to a PKI system as needed.

Even without crypto-all-the-way, we can still use a PKI accreditation
scheme to serve as a trust metric for domains.  Right now it's a PITA to
figure out which of a hundred nebulous blacklists you're on, and to try
to get them to delist you.  If we can somehow convert that cost (in time
and effort) into a money cost where you pay someone to accredit you,
people would breathe a sigh of relief: it's just more efficient that
way.  Accreditation could be done through any number of means, including
bonded sender, micropayments, whatever.  We need to explore this
further.

-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡