[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[FYI] (Fwd) FC: Critique of "TRIPOLI" authenticated email proposal



------- Forwarded message follows -------
Date sent:      	Fri, 9 May 2003 00:31:03 -0400
From:           	Declan McCullagh <declan@well.com>
To:             	politech@politechbot.com
Subject:        	FC: Critique of "TRIPOLI" authenticated email proposal
Send reply to:  	declan@well.com

The below discussion is from cypherpunks. The relevant graf from the
TRIPOLI proposal is this: >For Tripoli Pits to be useful resources for
e-mail processing and >handling, it is absolutely critical that they
be certified by >external, third-party certification entities. Without
certification by >trusted third-parties, such an authentication system
would be useless >since it could not be trusted to provide accurate
and valid >authentication data.

This is not a new breed of proposal. Ideas for certified email have
been around for over two decades, if we go back to a 1982 report by O.
Goldreich of the computer science department of the Technion, Haifa,
Israel. Many IEEE-published papers in the 1990s explored the field
(see this bibliography:
http://www.cs.jhu.edu/~ateniese/papers/ndss01.pdf), though the primary
focus was not on using it as an anti-spam technique.

My view is that it may be an interesting academic problem, but
actually implementing and deploying a Trusted Third Party scheme for
email runs into a number of practical problems, some of which are
described below.

Oh, and here's a Slashdot thread:
http://slashdot.org/comments.pl?sid=63556&cid=0&pid=0&startat=&thresho
ld=1&mode=nested&commentsort=0&op=Change

-Declan

---

From: Nomen Nescio <nobody@dizum.com>
Date: Fri,  9 May 2003 03:50:02 +0200 (CEST)

Lauren Weinstein, founder of People for Internet Responsibility, has
come out with a new spam solution at
http://www.pfir.org/tripoli-overview.

According to this proposal, the Internet email architecture would be
revamped.  Each piece of mail would include a PIT, a Payload Identity
Token, emphasis on Identity.  This would be a token certifying that
you were an Authorized Email User as judged by the authorities.  Based
on your PIT, the receiving email software could decide to reject your
email.

   It is anticipated that all Pits considered acceptable by the vast
   majority of all Tripoli-compliant software user would be digitally
   signed by one or more designated, trustworthy, third-pary
   authorities who would be delegated the power to certify the
   validity of identity and other relevant information within Pits.

In other words, here comes Verisign again.

   It is anticipated that in most cases, in order for the sender of an
   e-mail message to become initially certified by a Pit Certification
   Authority (PCA), the sender would need to first formally accept
   Terms of Service (ToS) that may well prohibit the sending of spam,
   and equally importantly, would authorize the certification
   authority to "downgrade" the sender's authentication certification
   in the case of spam or other ToS violations.

Thus you have to be politically acceptable to the Powers That Be in
order to receive your license to email, aka your PIT.  And be careful
what you say or your PIT will be downgraded.

Unfortunately he doesn't discuss various crypto protocol issues:

If the PIT is just a datum, what keeps someone from stealing your PIT
and spams with it?

If the PIT is a cert on a key, what do you sign?  The message?  What
if it gets munged in transit, as messages do?  You've just lost most
of your email reliability.

Or maybe you sign the current date/time?  Then delayed mail is dead
mail.

Or maybe you respond to a challenge and sign that?  That won't work if
relays are involved, because they can't sign for you.

Spam is a problem, but it's no excuse to add more centralized
administrative control to the Internet.  Far better to go with a
decentralized solution like camram.sourceforge.net, basically a matter
of looking for hashcash in the mail headers.  This raises the cost to
spammers without significantly impacting normal users.

---

Date: Fri, 9 May 2003 03:40:24 +0100
From: Adam Back <adam@cypherspace.org>

Yes, there is some discussion of it on slashdot, including several
other people who have commented similarly to anonymous that it is a
pretty big privacy invasion and centralised control point problem.

The claim that you can optionally be anonymous and not use a cert, or
get an anonymous cert is plainly practically bogus.  You'd stand about
as much chance of having your mail read as if you shared mail hub with
spamford wallace -- ie 90+% of internet mail infrastructure would drop
your mail on the floor on the presumption it was spam.

Plus a point I made in that thread is that it is often not in the
internet user's interests to non-repudiably sign every message they
send just to be able to send mail because that lends amunition to
hostile recipients who from time-to-time target internet users for
bullshit libel and unauthorised investment advice etc. 

Companies also are I would expect somewhat sensitive to not signing
everything for similar reasons as those behind their retention
policies where they have policies of deleteing emails, files and
shredding paper files after some period.

In addition PKIs because of the infrastructure requirements have
probem complex to setup and administer.  So now we've taken one hard
problem (stopping spam) and added another hard problem (hierarchical
PKI deployment) and somehow this is supposed to be effective at
stopping spam.

In addition unless there is significant financial cost for
certificates and/or signifcant and enforceable financial penalty and
good identification and registration procedures enforced by the CAs it
wouldn't even slow spammers who would just get a cert, spam, get
revoked, get another cert and repeat.

Certificate revocation is already a weak point of PKI technology, and
to reasonably stop spam before the spammer manages to send too many
millions of spams with a cert, you have to revoke the cert PDQ!

And finally it all ends up being no more than an expensive
implementation of blacklists (or I suppose more properly whitelists),
because the CAs are maintaining lists of people who have not yet been
revoked as spammers.  Some click through agreement isn't going to stop
spammers.  Legislation or legal or financial threat is going to stop
spammers either because any level of registration time identity
verification that is plausibly going to be accepted by users, and this
is also limited by the cost -- higher assurance is more cost which
users also won't be willing to accept -- will be too easy for the
spammers to fake.  And email is international and laws are not.

It is pretty much an "internet drivers license" for email.

I also think that fully distributed systems such as hashcash are more
suitable for a global internet service.  My preferred method for
deploying hashcash is as a token exempting it's sender from bayesian
filtering, and any other content based or sender based filtering.

That way as an email user you have an incentive to install a hashcash
plugin http://www.cypherspace.org/hashcash/ because it will ensure
your mail does not get deleted by ever-more aggressive filtering and
scattergun blackhole systems.  The camram system
http://www.camram.org/ is a variant of this.

It also more directly addresses the problem: it makes it more
expensive for spammers to send the volumes of mail they need to to
break even.

Adam




----------------------------------------------------------------------
--- POLITECH -- Declan McCullagh's politics and technology mailing
list You may redistribute this message freely if you include this
notice.
----------------------------------------------------------------------
--- To subscribe to Politech:
http://www.politechbot.com/info/subscribe.html This message is
archived at http://www.politechbot.com/ Declan McCullagh's photographs
are at http://www.mccullagh.org/ Like Politech? Make a donation here:
http://www.politechbot.com/donate/
----------------------------------------------------------------------
---

------- End of forwarded message -------

-- 
To unsubscribe, e-mail: debate-unsubscribe@lists.fitug.de
For additional commands, e-mail: debate-help@lists.fitug.de