Re: CAPTCHA over smtp (yet another spam solution to discuss)

On Sat, Nov 11, 2006 at 04:44:23PM +0100, David Sanchez wrote:
> BTW: a big step forward of IM  (this time Instant Messenging :-P ) is
> that lists of blocked and admited. Moreover you said IM is centralized
> worldwide. Maybe for private IM but not for XMPP
> (http://www.xmpp.org/specs/rfc3921.html) also known as Jabber. Each
> domain has its own users, it's responsible of what their users do, and
> communicate with other domains via a well known protocol (see for
> example [email protected] can comunicate with [email protected].
> gmail.com <-> davidsm.com communication is seamless between both
> domains providers via Jabber/XMPP)
> 
> But the question is, how could you enforce MSN, AOL or Yahoo! enter
> the XMPP protocol?

But why would I want to? What does that protocol give that the others don't?

It might mean it's possible to 'gateway' between the systems as you
describe, so that a user on MSN (say) can communicate with a person on AOL
(say). However, such gateways can be built without the IM systems using the
same protocol; you can always build gateways to translate between them.

Similar trust issues would occur. Consider when an inbound message from
[email protected] arrives when I am logged into MSN. The only way I can be sure
it's valid is to trust *all* the peer gateways of MSN not to be able to
insert forged addresses. It's a smaller problem set than the problem of all
SMTP servers in the world trusting each other, but as the number of
independent but gatewayed IM systems increases, the problem will become
worse.

It works as long as the number of central, trusted IM servers is small. If
every man and his dog can run their own Jabber server, as they do for SMTP
servers, then either you get the same problems as SMTP, or you get only
partial connectivity as it's hard for a newcomer to persuade others to peer
with you. It might not be quite as bad as SMTP if there's no way of messages
to 'transit' intermediate systems, i.e. messages from domain1 to domain2
never go via domain3.

Now, what I'm thinking of, is instead of having a small number of trusted IM
systems, you have a small number of identity brokers.

The identity brokers would not provide any services such as IM per se. For a
broker 'foo.com', all it would do is:
- allow people to create identities (e.g. [email protected])
- allow people to authenticate to the broker
- assert identity on behalf of the person who authenticated

Unlike a CA, there would be no assertion about the actual identity of the
person, only that they were the person that created account '[email protected]'.
People would be free to create as many electronic identities as they wished,
as they do in the current Internet world.

Now, at the moment, E-mail addresses provide a similar service. Typically
when you sign up to a BBS:

1. You choose a login name (your identity on the BBS)
2. You tell the BBS your E-mail address
3. The BBS send you an E-mail containing a cookie, e.g. in a hyperlink
4. When you receive the mail, you click on the hyperlink cookie, which
   proves that you received it.

In order to receive the E-mail, you must possess the credentials (e.g. POP3
username and password) to access that mailbox. So this long process binds
your BBS identity to your E-mail address and your secret POP3 login.

However this process doesn't scale: every time you want to use a new BBS,
you have to go through this same signup process. Also, you have to keep
track of your identities on each BBS, with their own logins and passwords.
Additionally, a particular username which you normally use may not be
available on another BBS, because someone has already taken it. So if you
see a posting from "lastofthegeeks" on one BBS, it may be someone else than
"lastofthegeeks" on another BBS.

What I would like to see is the identity broker taking the place of the POP3
username and password for asserting identity.

In the case of a BBS, this would work very much like Passport - just a
centralised web login repository. However, unlike Passport, I'd want to have
a number of brokers using the same protocol, so if I login as [email protected] a
DNS lookup will automatically choose the correct identity broker and be able
to authenticate against it. That ends the monopoly.

In the case of IM or E-mail, at the start I would open a session to the
identity broker and login. The IB would then sign messages on my behalf, so
that the recipient would know for sure they came from me. (In fact, I don't
need to send any messages to the broker, only a hash. The broker would sign
the hash. It doesn't need to see the contents of any of my messages.)

This gives you much of the benefit of cryptographic security, without local
hassles of key management which most people can't do. Of course, you have to
trust your IB to behave honourably (e.g. not sign messages you didn't send,
or not allow intruders to have access to your account), and for their
service to be reliable. But since there's a multitude of these brokers then
you have some choice.

Regards,

Brian.