June 26, 2005
Marc Stiegler - An Introduction to Petname Systems
Petnames evolved out of hard-won experience in the Electric Communities project, and went on to become a staple within the capabilities school of rights engineering. But it wasn't until Bryce 'Zooko' Wilcox made his dramatic claims of naming that petnames really discovered their place in the financial cryptographer's armoury.
Petnames were previously undocumented in any formal sense and disseminated by word of mouth and tantalising references such as Mark Miller's Pet Names Markup Language. Marc Stiegler, visiting researcher at HP Labs, has now stepped up and collected the community knowledge into one introductory piece, "An Introduction to Petname Systems." He has done us a grand service and deserves our thanks for putting petnames onto an academically sound footing:
An Introduction to Petname Systems
Zooko's Triangle argues that names cannot be global, secure, and memorable, all at the same time. Domain names are an example: they are global, and memorable, but as the rapid rise of phishing demonstrates, they are not secure.
Though no single name can have all three properties, the petname system does indeed embody all three properties. Human beings have been using petname systems since long before the advent of the computer. Informal experiments with Petname-like systems in computer-oriented contexts suggest that petnames are intuitive not only in the physical world but also in the virtual world. Proposals already exist for simple extensions to existing browsers that could alleviate (possibly dramatically) the problems with phishing. As phishers gain sophistication, it seems compelling to experiment with petname systems as part of the solution.
We seek comments below. Petnames is a very important concept in naming and if you design complicated financial cryptography systems it will be well worth your while to be at least familiar with the arguments within.
Posted by iang at June 26, 2005 07:35 PM
Has this paper been online before? I distinctly remember reading it (or an earlier version thereof).
The conclusions are ilogically founded. There's no natural law preventing names from being global, secure, and memorable -- all at the same time. Your email address in ZMail <https://zsentry.com/index.html> is one such example.
Is "security" here not confused with "secrecy"?
Suggesting that something only known locally is safe sounds like "security by obscurity".
Daniel, this doc has been up for several months. I was just finishing the second (current) draft when ian was doing volume one for this blog.
Ed, I clicked on your name to see the zmail address you claim to be memorable, global, and securely unique. I got nothing. The HTML source I see is href="http:///index.html", so something went wrong, please post the example explicitly.
Twan, I presume you are referring to the petname as the thing which is local, and depends on localness for its security properties. There are actually 2 items in a petname system that are local and private: the petname is private to the "client", and the key's private key private key is private to the "server" (if implemented with ppk pairs). The important thing about the local petname is not that it is secret -- petnames are explicitly often guessable, usually based on the nickname. The key feature is that the petname is visually distinguished in the application user interface from nicknames, and from sites with no petname, so that the user knows that he himself is the author of the petname. This is what removes it from the domain of materials that the attacker has control over and/or can forge/mimic. Secrecy is not the security feature; visual distinctiveness proving it was created by the user himself for himself is the security feature. The fact that you could be confused about this will force me to review the doc, see how I can make it clearer. Thank you.
Marc, apologies, I think the link is fixed now, that was my fault, I posted it by proxy and didn't correctly set the link obviously...
So, since Ian fixed the page and you edited your post so the zmail address shows up correctly, I have looked again. I have the following observations:
-- The address you posted is the site to sign up for zmail, not a zmail address. Looking around the site, and searching the web, I found a curious shortage of materials that would explain how zmail works: the explanation in general was "try it, you'll like it". I couldn't tell what zmail used for addressing at all, it could have been a true petname system for all I could tell.
-- I hate signing up for stuff just to figure it out, but in despair I went ahead and clicked to sign up for a zmail account. Here I found my answer:
On the signup page, zmail asks for your email address, saying, "ZSentry Mail works with any Email Address you already have."
So zmail piggybacks on the existing email address namespace, which has the weakness claimed by Zooko. For example, my email address, email@example.com, is global and memorable, but not securely unique -- it is easily phished by the email address firstname.lastname@example.org, for instance.
Clicking on my name here will not let you see any email address that is memorable, global, and securely unique. It should, however, open the URL http://zsentry.com where you can make your own email address securely unique using ZMail, in addition to being (already) global and memorable. No one will be able to send a ZMail using your email address. Only you will be able to decrypt a ZMail sent to your email address.
Going to the heart of the claims, the claimed reason why an email address is not securely unique seems to be the DNS. However, as a counter-example and without changing the DNS, ZMail does make an email address securely unique.
Another counter-example is a sentence in the very essay above, where the contradiction appears rather clearly:
"Though no single name can have all three properties, the petname system does indeed embody all three properties."
True, the DNS has well-known faults (I know more than 41) but any limitation imposed on email addresses as a name system by the DNS is just an artificial restraint and should not be viewed as a property (or lack) of name systems in general.
That said, you can of course introduce the subject of petnames and make it stand on its own merits. My comment was simply to the point that claiming an ilogical foundation is not helpful.
For clarity, my current comment is in regard to your last paragraph. For the other points please see my last comment and the help pages available by clicking on "Support Help" at the botton of most pages.
Your paragraph says:
1. "So zmail piggybacks on the existing email address namespace, which has the weakness claimed by Zooko."
A secure system can be built using insecure parts (many examples exist). Yes, the DNS indeed IS subject to phishing but ZMail is able to prevent phishing and can, thus, make the email address uniquely secure without any changes to the DNS.
2. "For example, my email address, email@example.com, is global and memorable, but not securely unique -- it is easily phished by the email address firstname.lastname@example.org, for instance."
Which ZMail prevents. Please see the help pages https://zsentry.com/mail/email_security_faq.htm
and the "ZSENTRY LOGIN:" entry in the help page
>> 2. "For example, my email address, email@example.com, is global and memorable, but not securely unique -- it is easily phished by the email address firstname.lastname@example.org, for instance."
> Which ZMail prevents. Please see the help pages https://zsentry.com/mail/email_security_faq.htm
That faq page explains ZMail better than anything I'd googled or found on the zsentry pages heretofore. I am sure there is an obvious link to it, but I'd missed it before :-)
However, while explaining it better than anything heretofore, zmail still does not appear to prevent the use of the email address email@example.com, or any of a host of other names that may qualify as "mimics" for the skyhunter.com domain. Indeed, it dare not -- there may well be a perfectly legitimate marcs out there who owns the skyhunter.net domain, and you surely do not want to prevent him from being a zmail user :-)
What we have, in the event of a legitimate user with the firstname.lastname@example.org address, is a non-phishing but still serious breakdown of the global namespace. email@example.com and firstname.lastname@example.org can easily be confused, leading to mail sent to the wrong addressee. Sometimes this will cause barely a hiccup in the email exchange process. Sometimes this will lead to humorous anecdotes worthy of Shakespearean comedy (which often uses similar points of confusion as the core plot element). Sometimes this will lead to disasters that are life threatening to the person who didn't get the email he was expecting.
Phishing is just one of the more alarming of the many problems that arise from having a global namespace that enables mimicry. Perhaps zmail is a solution to phishing, perhaps not -- we could have an entirely different disputation on that. But it is not a solution to the core problem -- if you have a global namespace that tries to make the names memorable, the names become mimicable as as consequence. Such global namespaces also lead to legal fights over ownership, and howls of rage with the central authority (ICANN in the DNS case) over the politically sensitive decisions they make. Better to move to petnames :-)
Thanks for reading the FAQ. My comments are inlined below, after each of your segments.
>if you have a global namespace that tries to make the names
>memorable, the names become mimicable as as consequence.
Any name can be mistyped, re-encoded using a non-compatible code page, or simply misread.
What ZMail address authentication solves is preventing anyone else but you to send a ZMail from email@example.com while you alone control that mailbox. It also prevents anyone but you and the sender from reading a ZMail sent to firstname.lastname@example.org. ZMail address authentication has to do with the mailbox, as that cyberplace where messages are sent to (SMTP) and received from (POP).
NOTE: Authentication is not enough. The question is why can I rely on it? Self-assertions cannot induce trust -- "Trust me" does not work. ZMail's address authentication provides a safe and easy-to-use automation of a process of address reliance, upon which encryption and message authentication can be delivered. This goal required the elimination from the automated process of violations of those policies (i.e., vulnerabilities) that might be hard to recognize or difficult to foresee, such as mimicking. Mimicking does not work with ZMail.
>Such global namespaces also lead to legal fights over
Interesting you mention this. Please see my First Monday article, at a time when forceful arguments were being made by large trademark holders to subject control of domain names to trademark holders. In summary, there are many kinds of global namespaces (phone numbers, TMs, Domain Names, and IPs, for example), for everyone and they all serve different purposes. What causes legal fights over ownership is greed, not global namespaces. And I'm glad we have a more balanced legal ground, today, where the rights of domain name holders are also respected.
"Arguments for Recalling WIPO RFC3 and Proposal for DNS/TM Resolution", 1999, in http://www.firstmonday.org/issues/issue4_4/gerck/index.html
>and howls of rage with the central authority (ICANN in the
>DNS case) over the politically sensitive decisions they >make.
Interesting too. As I published elsewhere in April 2000:
"...there is nothing to be gained by opposing ICANN, because ICANN is just the overseer of problems to which we need a solution.
My point is that there is something basically wrong with the DNS and which precludes a fair solution - as I intend to show in the following text, the DNS design has a single
handle of control which becomes its single point of failure."
But having in the DNS a single point of failure is like having all our eggs in one basket.
It creates the kind of risk that, as long as we still have national economies competing against each other, the US government and its major corporate allies will do whatever is necessary to protect from foreign capture. My conclusion was that BECAUSE someone MUST control it, the US in its historical role decided to do it. Otherwise, one would have to entertain the possibility that someone ELSE would control it. The problem here is not ICANN or the US, but the DNS.
See E. *Gerck*, "*Thinking*" in Cook Report On Internet, ISSN1071-6327, Vol. IX No.1, April 2000, p. 23.
The introduction seems to dive in with many assumptions.
"Below, we have Zooko's Triangle overlaid with a petname system: ....... For the purposes of this document, we actually use an alternate rendering of the key points of Zooko's Triangle, Markm's Triangle [PNML]."
* In two short paragraphs you've introduced ZT, replaced it with MT, assumed two layers, and then leapt into the points. This is way too much for the new reader to untangle, and it leaves my wondering how many assumptions have been made here.
* The only way I can make sense of this is to now go back to the original referenced documents and re-read them all to try and work out what the difference is, and why it is important.
* The glancing reference to a new triangle I've never heard of ("MT") makes me wonder what's going on here - either you're saying this is a better triangle and you are not going to say why, or some sort of game is going on.
From my memory only, there is no MT. What there is (again from my memory), is that in [PNML], MM documented ZT in a diagram. I don't know if that is worth mentioning. But if it is, it seems to be no more than that - we use MM's description of ZT in diagramatic form.
* It seems like ZT (or any T) has been forgotten here. Yes, the points are described, but the logic and the reason they hang together in a triangle are not present, except in the abstract.
I would expect that this paper (in order to be cohesive) would need to rip the guts out of Zooko's essay and duplicate it in an entire section. Petnames do not make sense without that conundrum explained. I personally don't see a problem with that, you just start the section with "This section summarises [Zooko]." or somesuch.
But without that discussion, there is this huge assumption that the user already knows where you are heading... You haven't established why there are 3 points, why there are three lines joining the points, and why each of those points and lines are so-named. Why can't we have a square?
* Where does this set come from:
"Each name set consists of three elements" ...
Why is it being introduced? Why is it necessary or useful to contain the discussion into this set? Are you asserting that all name systems are of a set like this? Or just Petname systems? (Neither make sense to me, but neither does the introduction of the set without explanation of how we got to this set...)
* Here's where I'm at. I'm trying to see if you've nailed down the definition of Petnames in some sense that then can be related to the anti-fraud discussion on which is the truer implementation of petnames in a toolbar ... but I'm left with the impression that I now have to go back to the original essay and re-read it.
* The mission (IMHO) should be to bury Zooko's original essay so that nobody ever needs to read it again. (Sorry Zooko.) Otherwise, you can't establish the groundwork to make petnames "special" in the way they solve problems.
By nobody, I mean of course nobody but academics who need to research and rebuild from first principles the entire thing. The general readership - our average technie - should not need to read anything but this one document.
i want to now more about u guys.
That is an excellent paper on petnames. I thought of another good example of a petname system that most people are familiar with. The phone books in cell phones have almost all the characteristics of a petname system. When I save a phone number in my phone book, I give it a petname. When I make a call, I look up the number by petname. When I receive a call, the caller ID shows me the petname. If you look at the all of the required characteristics of a petname system, cell phones have all of them, except that they have no suggested nicknames when I add new phone numbers to the phone book.
Yes, the cellphone's handling of names is an excellent example! Thanks.