Failure of PKI in messaging

James A. Donald jamesd at echeque.com
Wed Feb 14 16:35:19 EST 2007


Ivan Krstić wrote:
 > This is, in my experience, exactly right. I'm trying
 > to take some steps for the better on the OLPC: all
 > e-mails and IMs will be signed transparently and by
 > default, with the possibility of being encrypted by
 > default in countries where it's not a problem. This'll
 > help with privacy and message integrity, but it's not
 > designed to stop phishing or impersonation.

Matt Blaze has proposed despair - that message
authentication cannot defeat phishing,  Ivan Krstić has
proposed a system not intended to address phishing.

Naturally I have a solution - the only problem is to get
from where we are to there.  I was interested in the
banks perception that PKI was not working - what led
them to realize that PKI was not working or led them to
doubt that PKI would work, for in order to get from here
to their, have to persuade them that my solution *will*
work.  I was hoping for a response from the usual
defenders of PKI, who would, I hoped, give me the inside
scoop on the problems that Verisign has encountered with
its customers.

The solution to phishing:

Suppose we have a messaging service that, like Yahoo, is
also a single signon service, and, like OTR or Skype
voice messaging, delivers authenticated encrypted
messages.  Better, multiple such message services that
interoperate.

Suppose that when you register at a website for single
signon onto that website you get an icon in your
messaging client similar to a buddy icon, but
corresponding to that website instead of a buddy.
Zooko's rules apply - default name is title of logon
page that the user will see when logged in, but name is
local, user can modify it.  User has to handle name
collisions locally.  Click on the icon in your messaging
client, your browser is launched and logged on at the
web site, and that is the *only* way you can logon onto
that website in your single signon identity.   We want
the name of icon to default to same title as the logged
in page, for consistency with the experience of using
favorites -

The user experience should resemble using buddy icons
and also resemble using favorites icons.  When you click
on a registered website icon, instead of getting a text
box to type in a message, you instead get a browser page
logged in to the website.

If the web site is on the user's list for single signon,
then by default the website is enabled to send him
messages.  Only his buddies and enabled websites can
send him messages, and they can only be enabled if he
has an icon in his messaging system that represents
single click login.

The website sends message title and a url argument. User
sees a button, and the text "<message title> from
<user's name for website>".   If he clicks on that
button, he gets logged in as usual, but instead of
seeing his usual web page, sees a web page with that
title, that web page containing the actual message body.
Thus the user typically sees in his messaging client an
email like list of messages each with a button/link that
says:
	<title of target web page> from <title of usual
	login page>

These messages are given less immediacy than messages
from buddies - they are just put in a list like email,
for there is no live human waiting at the other end. The
single signon icons work like both buddy and favorites
icons, but the message icons work like email icons, not
like popups from actual buddies.

I have described the user experience, not the underlying
crypto, for everyone on this list can see how to use
crypto to give effect to the behavior described and
prevent adversaries from spoofing that behavior, but had
best post up the underlying crypto shortly, lest some
troll patent it.   The underlying crypto is, of course,
similar to that used by Skype and OTR, plus for the
login phase similar to the petname tool and OpenID.

It is not at all clear, however, how to make this
interoperate with Jabber/XMPP, for last time I checked
Jabber had no capabilities discovery mechanism, and in
consequence all the various officially approved jabber
encryption protocols were useless for any sane purpose.
On the other hand, the core of OpenID is nothing but a
capabilities discovery system, so perhaps some
combination of Jabber with OpenID could work.  I have
not thought the issue of Jabber compatibility through.
I participated briefly on that standards list, and
came to the conclusion that they could not run a
lemonade stand, much less produce a useful standard.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list