diff --git a/docs/mkdocs.sh b/docs/mkdocs.sh index 92478a2..be0f891 100644 --- a/docs/mkdocs.sh +++ b/docs/mkdocs.sh @@ -1,5 +1,6 @@ #!/bin/bash set -e +echo `dirname $0` cd `dirname $0` if [[ "$OSTYPE" == "linux-gnu"* ]]; then @@ -29,7 +30,7 @@ do then katex=" --katex=./" fi -if [[ $line =~ notmine$ ]]; +if [[ $line =~ notmine ]]; then mine=" " fi @@ -42,7 +43,7 @@ if [[ $line =~ notmine$ ]]; fi done cd libraries -options=$osoptions"--toc -N --toc-depth=5 --wrap=preserve --metadata=lang:en --include-in-header=./icon.pandoc --include-before-body=$templates/before.pandoc --css=$templates/style.css --include-after-body=$templates/after.pandoc -o" +options=$osoptions"--toc -N --toc-depth=5 --wrap=preserve --metadata=lang:en --include-in-header=./icon.pandoc --include-before-body=$templates/before.pandoc --css=$templates/style.css -o" pwd for f in *.md do @@ -50,6 +51,7 @@ do base=${f:0:($len-3)} if [ $f -nt $base.html ]; then + mine="--include-after-body=$templates/after.pandoc " katex="" for i in 1 2 3 4 do @@ -58,16 +60,20 @@ do then katex=" --katex=./" fi + if [[ $line =~ notmine ]]; + then + mine=" " + fi done <$f echo "generating $base.html from $f" - pandoc $katex $options $base.html $base.md + pandoc $katex $mine $options $base.html $base.md #else # echo " $base.html up to date" fi done cd .. cd names -options=$osoptions"--toc -N --toc-depth=5 --from markdown+smart --wrap=preserve --metadata=lang:en --include-in-header=./icon.pandoc --include-before-body=$templates/before.pandoc --css=$templates/style.css --include-after-body=$templates/after.pandoc -o" +options=$osoptions"--toc -N --toc-depth=5 --from markdown+smart --wrap=preserve --metadata=lang:en --include-in-header=./icon.pandoc --include-before-body=$templates/before.pandoc --css=$templates/style.css -o" pwd for f in *.md do @@ -75,19 +81,22 @@ do base=${f:0:($len-3)} if [ $f -nt $base.html ]; then + mine="--include-after-body=$templates/after.pandoc " katex="" for i in 1 2 3 4 do - read line - if [[ $line =~ katex ]]; - then - katex=" --katex=./" - fi + read line + if [[ $line =~ katex ]]; + then + katex=" --katex=./" + fi + if [[ $line =~ notmine ]]; + then + mine=" " + fi done <$f echo "generating $base.html from $f" - pandoc $katex $options $base.html $base.md - #else - # echo " $base.html up to date" + pandoc $katex $mine $options $base.html $base.md fi done cd .. diff --git a/docs/names/petnames.md b/docs/names/petnames.md new file mode 100644 index 0000000..bb37ad7 --- /dev/null +++ b/docs/names/petnames.md @@ -0,0 +1,956 @@ +--- +title: An Introduction to Petname Systems +# notmine +--- + +::: {style="text-align: center;"} +by +Marc Stiegler, Feb 2005, copyright under the MIT X License\ +updated June 2010\ +::: + +# Abstract + +Zooko's Triangle \[Zooko\] 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. Informal +experiments with petname-like systems suggest that petnames can be both +intuitive and effective. Experimental implementations 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. + +# Basic Petname Layout + +Below, we have Zooko's Triangle +overlaid with a petname system: + +![](./zooko-triangle.gif) + +For the purposes of this document, we actually use an +alternate rendering of the key points of Zooko's Triangle.  The +points +of the triangle are: + +- Memorable: this means + that  a human being has a chance of + remembering the name. Memorable names pass the "moving bus test": if + you see the name on the side of a bus as it drives past you, you should + be able to remember the name long enough to use it when you get home. +- Global: this means the name + is publicly available, and indeed the entity to whom the name is + attached is eager to give it to you. A key goal of marketing and + advertising is to capture memorable names in such a fashion that the + memorable name is globally locked to a particular entity. +- Securely Unique: This is + means that the name cannot be *forged* + or *mimicked*. + A name can be forged + if one can + manufacture an exact duplicate of the name such that neither man nor + machine can tell the difference. A name can be mimicked + if + one can make a name similar enough to fool the human being. In general, + phishing depends on mimicry, not forgery. This difference becomes + crucial later in the discussion. + +Each name set consists of three +elements: a *key* +that is global and securely unique (but not necessarily memorable); a *nickname* +that is global and memorable (but not at all unique) , and a *petname* +that is securely unique and memorable (but private, not global): + +- **Keys** lie at the heart of the security properties + of the petname system. Nicknames and petnames exist to make it easy for + human beings to manipulate keys. The security of the + system can be no stronger than the unforgeability of the keys. + Self-authenticating public/private key pairs make excellent keys since + they have strong + unforgeability properties. But there are other ways of achieving + unforgeability. A trusted path can also work well as the key: the full + pathname to a file on a specific computer is + also unforgeable (or at least, as unforgeable as the designation of the + specific computer, which can be quite strong in some cases). It does + not make any difference in a petname system whether a key can be + mimicked: keys are handled only by the computer, the human being + handles the keys only indirectly via petnames. For a particular person, + for a particular application, there is a + one-to-one mapping between a key and a petname. + +- **Nicknames** + can be used to assist in discovery of + keys, and for help in selecting a petname. Nicknames are chosen by the + owners of  keys in hopes of creating a distinctive, if not + unique, + mapping from the memorable nickname to the key. Such nicknames often + are promulgated throughout the world in + the hopes of making the nickname stick in the mind as a reference to + the + key. Since there are strong incentives to "take ownership" of a + nickname, even though true ownership is not possible, nicknames are the + most often misunderstood part of a petname system. + + In the simple case, a nickname has a one-to-many mapping to + keys The name John Smith is obviously a + nickname: there are many John Smiths.Other nicknames + produce the illusion of being globally unique: the name Marc Stiegler + appears to be globally unique at the time of this writing. But there is + no security property in this accident of global uniqueness. The + uniqueness of the name Marc Stiegler would change quite quickly if, + through the + mysterious forces of human whimsy, the name suddenly became desirable. + Sometimes the desirability of a nickname is not whimsical, but venal. + It is already desirable for some applications to call + themselves + Quicken, for example, and draw windows that request a Quicken password. + +- **Petnames** + are our private bidirectional + references to keys. + There are many Mark Millers, but there is one specific Mark Miller that + the + name means to me, the Mark Miller who + works with object-capabilities for secure cooperation. "Mark Miller" is + Mark Miller's nickname; it also + happens to be my petname for the same individual. My private pet name + for my wife is not recognizably similar to the public nickname used by + my wife. In the computer setting, for a specific person with a specific + application, petnames are unique, each petname refers to exactly one + key, and each key is represented by exactly one petname. In all places + in + the application where the app wants to designate the key, the petname + is displayed -- which is to say, *a + true petname is a bidirectional one-to-one mapping to a key*. + All references to the key by the user interface are represented by + petname. + A key cannot have two petnames; if a single key had two petnames, under + what circumstances would the user interface use petname1 as the + representation of the key, and under what circumstances would it bring + up petname2? + +## More Detail, and Interactions + +A good example of a nickname management system is Google. Type +in a name, and Google will return a list that includes all the entities +Google knows, to which the name refers. Google +makes a mapping between these nicknames and their keys (if we think +of the url of a page as a trusted-path-style key, which will be +discussed later). Often +enough to be interesting, the first item in the list will be the one +you wanted. But it fails often enough, and endless pages of other +choices appear often enough, to never leave us in doubt that these +identifiers +are not unique mappings to single keys. As is already true in the +current world, in a world filled with petname +systems, a key goal of marketing would be to get your nickname listed +at the top of the Google rankings for that nickname. + +A single key may map to multiple nicknames. The entity that comes up +first in a Google search for "Marc Stiegler" is an entity who proposes +the +nickname "marcs" for himself in many forums. However, to assess the +security +properties of a petname system, this is irrelevant. + +Nicknames are conveniences that may serve as good starting points +for petnames. If I send +you my key and my nickname, often my nickname (which I normally will +have chosen to +be reasonably rare in the world) will work great as your petname. But +do not confuse the nickname-as-proposal with the +petname-as-decided. Never in a true petname system is +the nickname presented or employed as if it were a petname. + +*Alleged names* +are similar enough to nicknames to be worth +distinguishing. An alleged name is the name for an entity proposed by a +third party, typically in an introduction. This can also be useful as a +starting place for picking a petname. Alleged names, like nicknames, +are usually memorable, often global, and never securely unique. Alleged +names are often based on nicknames, though this is unreliable enough, +if one really cares about the nickname then one really needs to ask the +entity holding the key, not the introducer. + +In action, keys and alleged names +tend to be transferred together. We +refer henceforth to such key/alleged-name pairs as *referrals.* + +It is crucial not to confuse +private petnames with global nicknames +that temporarily happen to have a unique mapping to a key. +Experience to date suggests that the word "petname" is attractive, +leading people to desire to use it. People can thence easily fall into +the trap of referring to momentarily +unique nicknames as "petnames". This error then leads them inevitably +to draw fatally confused conclusions about the possibility of petnames +with global meaning. The security properties of a petname come from its +privacy. Public nicknames are trivially vulnerable to +both forgery and mimicry; they have no security properties. + +Petnames are guessable. Most people will accept Paypal's nickname as +the petname. This can only impact the security of the +system if the user interface +distinguishes the petnames from the nicknames so poorly that the user gets confused. + +The term "petname" suggests that this name is embodied as text. This +is +not necessary; petnames can be graphical as well. Indeed, some of the +petname systems listed later use petnames that include both *pet +texts* and *pet graphics.* + +Petnames must be repeatably editable by the human being so that the set +of petnames can evolve as the user's set of associations +grow. +You might use the petname "Mark Miller" for the one and only Mark +Miller that you know. But then if you meet another Mark Miller you will +have to distinguish, possibly by editing the first one: the single +entry "Mark Miller" may now split into "Mark Miller Capability Guru" +and "Mark Miller Dentist". + +Petnames convey power: since the petname is the user representation +of the key, it is through the petname that the human +being +uses the key, communicates with the key owner, and conveys authority to +the key owner based on the user's *purposeful +trust* +relationship with that owner (*purposeful +trust* is the type of +trust +needed to engage in action: I trust (i.e., I am willing to be +vulnerable to) Entity X to hold N number of +dollars on my behalf, and to engage in transfers of that money based on +orders I give). + +Another way of thinking about the relationship between a key and a +petname is this. The key is used to authenticate the entity that owns +the key. The petname is used as a handle upon which to hang the +trust/reliance/vulnerability data used by the human being to make +authorization decisions for that entity. If the entity represented by +the petname My Phone Company asks for my credit card, if the +justification sounds reasonable, I will release it. If the entity +represented by the petname Deadbeat Brother (whom I nonetheless trust +to teach my daughter soccer in the afternoon without supervision -- the +trust relationship with such a brother is neither positive nor +negative, it is complex) asks for my credit card, I will not release it +no matter what the justification.*\ +* + +*The security +of a petname system depends on the +keys to +prevent forgery, and on the petnames to prevent mimicry.* + +# Petnames In Action + +Informal +experimentation suggests that a petname system is +much easier to use than to explain (see examples below). We will create +a single example for this introduction, and give some hint as to the +wide diversity of variations in the Examples. Suppose I send you Mark +Miller's OpenPGP pubkey in email. I say, "here is mark miller's +pubkey." +I sent you both a key  and an alleged +name +(mark miller). Implicit in the transmission of the alleged name is the +proposal that you might want to consider "mark miller" as the petname. +What you actually choose as a petname depends entirely on your context. +If you know this particular mark miller in other contexts in other +applications as "markm", you may choose "markm" as the name referring +to this key in your list of pubkeys. If you think this might be +the same mark miller, but are not willing to be vulnerable to me as the +sole source of such +powerful mapping, you might use the petname "Marc Stiegler's Mark +Miller" or "Mark Stiegler's markm". If you perform appropriate +incantations on the pubkey, you can get the entity's nickname. If this +pubkey already exists +in your list, your software shouldn't give you the choice of adding it: +the software should tell you that you already have this one, and tell +you the current petname (and perhaps bring up the petname editor so you +can change the petname if the newly-received reference suggests a +better name). If you receive a message signed with the private key for +the markm petname's pubkey, the software should display the +petname markm. If you send a +message to mark miller, you should pick the +encryption key based on the petname. + +The above example has the +security properties of a petname system, but OpenPGP systems often do +not demonstrate the  usability properties a petname system +needs. +Instant messaging systems with buddy lists demonstrate the usability +properties, but for reasons beyond the understanding of this author, +discard all the security properties. See the examples section for more +details on buddy lists as petname systems.\ + +# Key Issues with Petname Systems + +Two elements of full-fledged +petname systems seem to be principle +sources of controversy. One is, how do I get the keys transferred +around the system? The other is, "how easily can Darth Vader mimic a +petname?". + +## Transferring Keys and Purposeful Trust + +Transferring keys around the universe is easy; for example, plaster the +keys on all the web sites in the world that'll let you do so. The hard +part is transferring a key with an association to purposeful trust. It +is useless to both PayPal and the phisher who wants your Paypal account +if you just know Paypal's key; you have to be willing to make yourself +vulnerable to the entity who +owns the key to hold your credit card, trusting him to engage in only +transfers that you specify. + +The question, "how do I +transfer a purposeful +trust association?", is hard to +answer because there is no simple single answer. Instead, there are a +vast array of +answers, each of which works in narrow circumstances. The question +is made +even more difficult to answer because the mechanisms by which humans +determine an appropriate purposeful trust to be associated with an +entity +is subtle, complex, powerful, and completely subconscious: the +question of how you transfer the association can easily slide into a +hopeless discussion of how to create purposeful trust in the first +place. Here we outline some general ideas for transferring +key/purposeful-trust +mappings, then in the +Examples +point out some practical approaches in specific narrow contexts. + +Answers often start with direct +physical contact. You get a combination of +a nickname and a key in a file from your best friend, who says, "this +Google thing is a great search engine", or "this Consumer Reports site +will not lead you astray". You stick these referrals in your browser, +assign petnames, +and make yourself vulnerable to them for the purposes stated because +your friend said so. +Then when the side of the bus says PayPal, you might go and see what +Google thinks Paypal means. Since a relationship with PayPal is a +serious vulnerability decision, serious enough so that we're not going +to jump +at the first site just because Google said so, we'll ask a few of our +friends to email referrals to the entities they use for online money. +If the referrals they send all share the same key as the Google +key (which is easy to tell, because trying to add each new key/petname +mapping will +produce the alert that the key matches something you've already got), +the +quality of your willingness to be vulnerable to the key you have +petnamed PayPal improves. +This is pretty similar to how +we all started using PayPal even without the petname system: we jumped +in when enough of our friends and organizations that we trust for +recommendations about financial matters concurred. The only difference +in the petname version of the story is that our friends explicitly gave +us referrals rather than easily mimicked domain names, and we +explicitly set a petname (perhaps by just clicking an Accept key when +the alleged name was proposed as the petname). + +While a full-fledged, purebred +petname system could in principle +supplant the entire DNS system, we have DNS now, and we can use it to +do some bootstrapping.  My ability to type google.com and +paypal.com is probably adequate to get started. + +Regardless of how you +bootstrap, you +can get referrals by email, thumbdrive, web page, chat, and even by +telephone. + +## Converting From Nickname to Petname + +The other part of the system +that is impossible to quantify is the +mimicability of pet names. Let us assume a poorly built petname system +in the clutches of a clueless user. We have a money transfer site +on the Web that we have petnamed PayPal. We get an email telling us to +update our PayPal account, we click the link, and go to a domain that +has given itself the nickname PayPa1 (for those of you with typically +broken fonts, that last character, "1", is a one). Our poorly +built  hypothetical petname system +is so poorly +built, the nickname is put into the field where the petnames go, with a +hint of  shading or some other easy-to-miss mod to mark the +fact that +this is the web site's nickname for +itself, not our petname for it. The  distinction is missed, +and +our +user is phished. + +The solutions to this problem +are +application and context specific, +though there are some good ideas floating around that seem to have wide +applicability. In the Waterken Petname Toolbar proposal (see below), +the alleged name is always "untrusted".  It's hard to fail to +recognize +that +this isn't PayPal, though a sufficiently unobservant user might +completely disregard the petname and nickname information and get +phished anyway. There is limited informal evidence that users really do +notice things like this (see below), and so the most cynical of +skeptics are probably mostly wrong though they are probably slightly +right: if you send a million phishing emails to each of a million +users, some day some one will be tired and unobservant and will get +phished. If sending a trillion emails like this is cheap enough, +phishing will remain profitable, so part of the solution needs to be +making a trillion emails ever so slightly expensive. Regardless, +multiple experiments with multiple +user interfaces would be a good idea to help develop user interfaces +that maximize the probability that a tired unobservant user will notice +a warning. + +There are a couple of user +interface issues. The petnames must be unambiguously distinct from +nicknames. This seems easy to do, through colors, fonts, additional +text, and separate fields for the nickname as examples of pieces of +strategy. + +More difficult is the following +problem: Petname creation must be +both painless (or people will reject the whole idea) and reliably +mimicry-free (it would be a disaster to have both PayPal and PayPa1 as +petnames!).  Is this one of those hopeless tradeoffs that the +computer security community enjoys throwing in its own face? To the +author, this +problem looks solvable; indeed, it seems hard to believe that this +cannot be solved with some reasonable satisfaction, given the number of +user interface ideas for this problem floating around. But +implementations and experiments, will be required to identify minimally +intrusive, adequately effective solutions.  + +Here are two example ideas +for petname creation user interface +that seem generally applicable. First is to compose the default choice +for the petname out of a combination of contextual information and +nickname information. Suppose we click on a link to "PayPal" in the +Consumer Reports site (that is, the site that we have assigned the +nickname, "Consumer Reports"). This takes us to a new site that +proposes the nickname "PayPal". The system clearly marks that we do not +have a petname for this site and proposes "Consumer Reports's PayPal". +The user can press a button to accept this name, edit it, or, with +algorithmic chicanery left as an exercise for the reader, press a +second button that says, "let me use the raw nickname PayPal as the +petname." This system still depends on the user remembering the +petnames he has already assigned and noticing at the time of creation +of the new petname, whether he already has a similar name in his list. +This by itself is probably enough to protect the PayPal pet name -- +most of us who gave PayPal a petname would have no trouble remembering +we had done so, and if we saw something that looked like "PayPal", we'd +notice we were at risk of confusing ourselves if we accepted a similar +name -- but again, we are dealing with humans, so the process is +imperfect. To support the human being, we'd want to use a font that was +as ambiguous as possible during petname creation, mixing up 1 and l and +I in a hopeless mess, +so that we could be confident that our petnames looked unique no +matter what ridiculous font got used later. + +The second idea is to have a weak algorithm for comparing a candidate +petname in the act of being accepted to the existing petnames. We +explicitly call this a *weak* +algorithm because it can be +pretty poor. It  is quite +acceptable for the algorithm to pop a list of "similar petnames" that +is overly extensive, i.e., it is fine to show names that the human +easily recognizes as distinct. The serious error is to fail to show +names that +the human might confuse. Comparing Paypal to Paypa1, a sample algorithm +might notice that the names are of similar length and have three +letters in common ("p", "a", and "y"), and say, "that's similar enough +to worry me, I'm gonna check with the boss." The algorithm for noticing +similarity between private petnames is under much less pressure to be +perfect than is the algorithm for a Certificate Authority when deciding +whether +to award the name "pawpal" when the name "paypal" already exists. A CA +might like to prevent mimicry, but to do so must tread a +difficult line with abolishing huge swaths of namespace to ensure +similarities don't arise. + +However it is done, mixing alphabets from different languages into a +single petname list is ridiculous. These are private petnames. Only one +person in the whole world needs to read them. Use the user's default +character +set, and be done. + +# Examples, Near Examples, and Comparisons + +## Physical World Petnames + +Humans have been using parts of +petname systems since before the +invention of the written word. Human faces +were used as keys. These keys resisted forgery far better than most +things that pass for security today on computers (except in episodes +of Mission Impossible, and the occasional Shakespearian comedy like +12th Night). The referral, "Joe, this is my son Billy, +he's great with a club," transferred both a key/alleged-name pair and a +first-order +purposeful trust recommendation. The recipient of this referral +typically accepts the alleged name as a petname, though in some cases +the recipient may instead choose other petnames, such as, "Bob's big +dumb dufus of a son", which is a strictly private petname. + +These physical world petname +systems were sufficiently different +from computer-based petname systems that it is dangerous to draw too +many conclusions from them. But the similarities are sufficiently +intriguing that the author feels compelled to mention them. More +comprehensive comparison and contrasting of physical petnaming to +computer-based petnaming is left as an entertainment for the reader. + +## Trademark Law + +Trademark law is not a petname +system. When civilization started +creating entities that did not have unforgeable faces (like Apple +Computer), we settled on a legal system that attempted, with fair +success, to enforce (that is, secure) purpose-unique memorable +global IDs for small numbers of entities. It is hard to map trademarks +onto petname systems for comparison, but an attempt seems in order. The +trademark-purpose pair is the key, made unforgeable by government +coercion. It +is important to note that the trademark itself is not the key: Apple +Computer and Apple Music both used the trademark Apple for decades, +without conflict, until Apple Computer entered the music business. + +The trademark by itself is the +nickname: Apple Computer thinks of itself as "Apple". Petnames are +absent. Mimicry is prevented by the same +government action as forgery, and indeed the trademark system makes no +distinction between forgery and mimicry (which helps explain why the +distinction is so blurred in most computer security discussions). + +Trademark law depends on the +legal system to disambiguate "similar +purpose". This is expensive, and consequently trademark law can only +apply to "small" numbers of "big" entities. The name Mark Miller is +covered by trademark law, but only in explicitly recognizing that all +people who have that name may use it, i.e., trademark law recognizes +non-uniqueness in this case. On the Web, the number of entities with +whom we +would like to associate trust/vulnerability relationships is extremely +large; indeed, +one of the failures of the Web today is that we cannot construct as +many such associations as we would like. Those relationships span +multiple legal jurisdictions, further complicating the trademark +system. Trademarking simply does not scale well enough for the age of the Web, despite its success in earlier eras. + +## Instant Messaging Buddy Lists + +Buddy lists for instant messengers follow the logic of petname systems +quite closely, though all the security properties are discarded in current +implementations. Each entity gets a globally unique id, rooted in the +domain name of the messaging service, which fills the role of "key". A +weak effort is made to make the id both human memorable on the one +hand, and unforgeable, on the other. The id is used as a nickname; +being sometimes memorable, it works well enough often enough. The same +id is used as +a key even though it is easy +to forge (either through man in the middle attacks or password +attacks). +The important point is that, once the user puts a petname into the +buddy list, all references to the id are represented using the petname: +you +can connect to the entity using the petname, and when the entity +connects to you, the petname displays. + +Buddy lists are so intuitive, +people easily learn how to use them +with neither instruction nor documentation. An instant messenger that +used true keys, true nicknames, and enforced good security properties +would be virtually indistinguishable in user-interface presentation +from +existing systems; indeed, if one used an object-capability style of +key, the biggest difference would be the absence of passwords, an +actual usability improvement. Informal experimentation on a global +scale in the +instant messaging arena suggests the petname architecture embodied in +buddy lists can work well. + +## CapDesk and Polaris + +CapDesk \[CapDesk\] and Polaris \[Polaris\] are desktop systems that +explicitly flesh out a petname system to enforce security +properties. CapDesk is a point and click desktop that combines +usability, security, and functionality, to a degree often found +surprising by those unfamiliar with it. In CapDesk, at +application installation time the +application proposes a pet text and a pet graphic (the icon for the top +left corner, and the text in the title bar that is immediately +adjacent). The user may accept this petname or modify it. Windows +launched thereafter by the installed application are unforgeably marked +with the petname. Limited informal experimentation suggested that the +CapDesk petname system was intuitive and easy to use, like the buddy +lists. + +Polaris is a derivative of +CapDesk that defends the Windows +operating system against several interesting classes of attack. Polaris +uses pet texts similar to the CapDesk pet texts for marking the +windows. Polaris was used in a larger set of pilot programs than +CapDesk ever experienced. +One result of the pilots that proved a pleasant surprise was that +people were  aware of and sensitive to the petname markings. This +supports the hope that petnames could indeed strongly impact phishing. + +## Domain Names + +The DNS system is perhaps the most widely used naming architecture in +the world. There are a couple of ways of viewing DNS from a petname +perspective. The most clarifying view is perhaps the view of the domain +name as both key and +nickname rolled into one -- a unique nickname that must try to support +security +properties. One powerful way to describe DNS is to say that DNS strives +to make keys that are memorable. In other words, it is a direct +violation of Zooko's triangle. And that is why mimicry is possible. *Mimicry is an emergent +property of the violation of Zooko's +triangle.* Mimicry emerges as +the system grows to large scale. DNS is the leading example of the +problem. + +Several of the other examples +here treat the domain name as a trusted-path key. +Domain names are forgeable, but in practice they seem to be resistant +enough to forgery to be useful. Judging by the +prevalence of mimicry-based phishing over DNS forgery, it seems clear +that forgery is not the weakest link in DNS; mimicry is. + +## Browser Bookmarks + +Browser bookmarks combined with DNS have a remarkable similarity to a +petname system...with a fatal flaw. Think of the domain name as both a +key and a nickname (which is not fatal to a petname system, remember +the nickname has no security properties, it can be gibberish or +massively oversubscribed or mimicked without violation...though the +petname system has a better chance of success if users understand that +the nickname has no security properties, which is another problem with +DNS). With this characterization, the bookmark can be thought of as a +private name that points at the key, +suggested by the nickname. It sounds like a petname system. + +However, the bookmark is not a +petname. Technically, it is a +*lambda name*. As noted earlier, +a true petname is a +*two-way* mapping: any +reference to the key is represented in the user's world as the petname. +However, lambda names like bookmarks only map from the private name to +the key, with no mapping back. When you follow a bookmark to a page, or +take any other path to get to the page, the domain name is used +throughout the user interface as the "name" for presentation to the +user, a fundamental violation of petname logic. Despite this violation, +bookmarks plus DNS demonstrate how even a partial implementation +of petnames will deliver some of the defense against +mimicry that a full petname system can achieve. Any person who uses the +strategy of reading an email allegedly from PayPal, and then clicking +on their existing bookmark to go to PayPal rather than following the +email-embedded link, is getting a security benefit derived from the +partial implementation of petnames afforded by bookmarks. + +## OpenPGP and the Web of Trust + +OpenPGP keys +carry nicknames with them, and the user can replace nicknames with a +name of the user's choosing, which would be a petname. When an entity's +key is observed by the software, the pet name is properly presented, +i.e., the petname is properly bidirectional. +The Web of Trust supplies an interesting way to associate these keys +with purposeful trust, by asking other entities who have vouched for +the new entity, what they recommend as a trust relationship. + +With all these features, +OpenPGP supplies a true petname system +architecture. OpenPGP has not been tested by phishing attacks yet. +Since all the basic elements are there, the biggest question would be, +how must the user interfaces for applications using OpenPGP evolve to +face such a threat? This is another reminder that user interface is as +critical for any practical security architecture as is the crypto. A +security system whose user interface is written by cryptographers is no +more likely to succeed than a security system whose encryption +machinery is written by user interface designers. + +## Waterken Petname Toolbar + +This toolbar\[Waterken\] is a proposal for web browsers explicitly based +on petname +architecture, explicitly to prevent phishing. A certificate plus a +domain name is treated as the key. The petname is a true two-way +mapping between key +and private name. The alleged name for all sites is "untrusted"; there +is no nickname. For those +sites to which the user assigns a petname, the toolbar supplies +markings +that makes it easy for the user to unambiguously distinguish the site. +This toolbar has been implemented for Firefox. This author switched to +FireFox from Mozilla just to be able to use this tool. Limited +informal experimentation suggests that the petname toolbar is as +intuitive as the buddy lists and desktop systems described earlier. + +## Certificate Authorities + +Certificate +Authorities create +nickname/key pairs. The certificates +share with pgp keys the cryptographic strength to ensure +unforgeability. The claim is made that, because the nickname is unique +within the CA, interesting security properties may be ascribed to the +nickname. Petnames are not included in the scheme. It looks a fair bit +like DNS, with the CA root playing the role of the DNS root servers. + +How do CA-based +systems fair against mimicry? The similarity to DNS is certainly +suspicious. A generous author +might just say, CA defense against mimicry is controversial in theory +and untested in practice. A less generous author would probably say no +more, since such an author would still desire people who +think that CAs are beneficial to read the rest of the paper.\ + +## Trustbar + +The trustbar \[trustbar\] is a CA-based +browser system that +allows user construction of petnames, including both pet text and pet +graphics, for the certified entity.  In the 0.1 Mozilla +implementation, the distinction between a nickname (based on the cert) +and the petname is implied by the popup of a dialog box when the cert +is first encountered and no petname has yet been assigned. The petname +and the key are not quite fully bidirectional: the key is properly +represented by the petname in user interactions, but the petname cannot +be used to get to the key. This is just a quibble, however. The +Trustbar implements a petname system. It has, however, a big change +from a simple petname system: the inclusion of a +CA +in +the mix. Does this help +or hinder? + +In the presence of the popular +"Just click Ok" mantra for certs, adding a CA +to the system may introduce new vulnerabilities. Two CA-based +attack examples: "We here at Verisign are upgrading our root key. +Please +follow the link and click Ok." Alternatively, "We here at Paypal have +fallen +into a legal dispute with Entrust. We are using a new CA that is every +bit as trustworthy. Please follow the link and click Ok." Brief +informal experimentation with the author's 83-year-old mother-in-law +suggests that an email asserting Paypal has changed domain names is +easily recognized as an attack. However, email asserting a cert has +changed is +viewed as a foolish demand impeding progress -- just click OK. + +As noted earlier, user +interface design is every bit as important to +security as the strength of the keys. Simply stripping the trustbar +tool of the inevitable plethora of CA-related dialog boxes would +significantly improve usability, increasing the chances that real human +beings would tolerate it; all the security properties of a +petname system without CAs would remain intact. The Trustbar itself +pops dialogs at the user (sometimes several in a row, if the entity +maintaining a web site decides to use different certs for different +pages, as discovered during the author's experiments). Private +correspondence +with the designers of the trustbar suggest that evolution in a +direction reducing the frequency and annoyance of the dialogs is a +possibility. + +How well will the current implementation of the trustbar work in +practice? Only +experimentation can tell. + +## Pet Name Markup Language + +PNML is an XML proposal for +using petname systems ubiquitously. In a +chat system, if Bob made a reference to Alice in the text he wrote to +Ted, and if Alice is Bob's petname for a person known to Ted with +petname Carol, the sent reference to Alice would be converted via the +magic of computers into a received reference to Carol. It would take +more effort to build PNML into an existing browser than to +integrate the Waterken Petname Toolbar, but the results +would be interesting indeed. + +# Conclusions + +Many informal experiments with +systems identified here that use +parts +of petname systems +have +demonstrated that they can be intuitive and easy to use (Buddy Lists, +Browser bookmarks, the petname toolbar, and the CapDesk and Polaris +secure desktops). A user who +understands his petname system and is alert to the information it +conveys can be extremely hard to trick using mimicry, making that user +a difficult target for phishing. Experimentation is required to +determine how much less vulnerable to phishing the typical user would +become given a petname system. Experimentation with +petnames for web browsers does not have to be expensive; both the +Trustbar and the Waterken +Petname Toolbar are ready now, both for usage and for further +experimentation by building variations based on the open-source code. + +# Implementation Notes/Requirements + +Following are key features +of a petname system. If an +implementation of a naming system for an application does not include +these properties, it is not fully following the logic of petnames: + +- The key must be resistant + enough to forgery to survive in the + context of the application threat model. +- There can be at most one + petname per key per user per + application.\ +- There can be at most one key + per petname (per user per + application). +- In the application user + interface, all references to the key are + represented by the petname. +- The user must be able to + assign a private petname to any key. +- The petname must be assigned + to the key only by explicit user + action. +- The user must be able to + repeatedly edit the petname of any key. +- The user interface shall + assist the user in assuring that two + petnames are not similar enough to enable mimicry, to the extent + necessitated by the complexity of the application context in which the + petnames are selected and manipulated. If the number of petnames needed + by the application is small and they are easily remembered, no + assistance may be required. If the number of petnames is large, and/or + difficult to remember and/or likely to be similar, and the resultant + forms of mimicry, accidental or intentional, leads to vulnerability + inside the threat model, assistance is required. +- Nicknames and alleged names + must be unambiguously visually + distinct from petnames. +- Nicknames are optional. + +# Glossary + +**Petname +System:** a naming system in +which, for each +individual entity recognized by another entity, three interlocking +names solve Zooko's Triangle. The three elements are the key +(global +and secure), the nickname (global and memorable), and the petname +(secure and memorable). + +**Petname:** +This term has three distinct but related +usages in the literature on petnames. Sometimes it is used as a +shorthand for referring to the petname system as a whole. Sometimes it +is used as a direct reference to the naming element that is secure, +memorable, and private to the individual who refers to another +entity; this is the +meaning used throughout this paper. Sometimes "petname" is used to +refer to the textual component of a +petname (which may have graphical elements as well). In +contexts outside this paper, the reader must +ascertain the correct interpretation from that context. True petnames +are 2-way associative: given a petname in a specific application on a +specific machine, you can acquire the key, and given the key, you can +acquire the petname. The mapping back from the key to the petname is +always performed when presenting data to the user. This makes petnames +different +from lambda names, which only map from the name to the key. + +**Pet +Text:** A petname, or part of +a petname, that is textual. The +owner of a machine upon which a petname resides can edit the text to +modify the petname. + +**Pet +Graphic:** A petname, or part +of a petname, that is graphical. + +**Pet +Face:** A petname, or part of +a petname, that is an image of a +human face. Pet faces are intended to exploit the special powers of the +human mind for associating purposeful trust with another human. + +**Purposeful +Trust:** The type of +trust that is needed before a person +should empower another entity. Examples: "I trust Entity X to +hold N +dollars for me, and to perform transfers of that money on my behalf." +And, "I trust Entity Y to tell me whether or not to buy a car +from +Entity Z." We speak of purposeful trust to distinguish it from the many +other things computer people call "trust" these days. CAs, for +example supply "trust". But CAs do not tell you if you can trust a +certificate owner to pick up your garbage, or handle your +stock portfolio. It's just "trust". + +**Forgery:** +An exact duplication +of a key, such that neither human nor computer can distinguish the +duplicate from the original. + +**Mimicry:** +A duplication of +a name that is good enough to fool the human being, though not good +enough to fool a computer. A famous example is +the name *paypa1* +(with a "one" as the final character), +which mimics *paypal* +quite well. +The quality of the mimicry of paypal depends on the ambiguity of the +font in +use, and the alertness of the human reading the message. + +**Lambda Names:** +Names that are memorable, secure, and +private, but +which only map from the name to the key: given the lambda name, you can +retrieve the key, but given the key there is no mapping back to the +name. Objects in programming languages follow this logic: the +programmer gives the object a name in the program, but once compiled, +neither the object nor much of anything else knows how to get back to +the name (though this is an imperfect example, since debuggers can +indeed map back). Bookmarks in browsers are another example: the +bookmark maps to a url, but once you go to the url, the url is +presented directly to the user, not the name embodied in the bookmark. +Consequently bookmarks cannot help against phishing. + +# Acknowledgements + +Thank you to everyone on the Cap-Talk mailing list for their help, +especially Ian Grigg for his deliciously relentless criticism, but also +notably including David Hopwood, Alan Karp, Mark Miller, Tyler Close, +Trevor Perrin, and Charles Landau, each of whom made comments that +directly caused modification to the early draft. Thank you also to Amir +Herzberg for his assistance in understanding the Trustbar. + +# References + +\[Zooko\] \ +\[Trustbar\] +or [http://www.cs.biu.ac.il/\~herzbea//Papers/ecommerce/spoofing.htm](http://www.cs.biu.ac.il/%7Eherzbea//Papers/ecommerce/spoofing.htm)\ +\[CapDesk\] +or \ +\[Polaris\] \ +\[Waterken\] [](http://www.erights.org/elib/capability/pnml.html)\ diff --git a/docs/names/zooko-triangle.gif b/docs/names/zooko-triangle.gif new file mode 100644 index 0000000..b22ffe1 Binary files /dev/null and b/docs/names/zooko-triangle.gif differ diff --git a/docs/names/zookos_triangle.md b/docs/names/zookos_triangle.md index ec34572..9eb39f8 100644 --- a/docs/names/zookos_triangle.md +++ b/docs/names/zookos_triangle.md @@ -11,7 +11,7 @@ how do you know you have the right “Bob”? There are a lot of Bobs. Zooko’s triangle is the solution to this problem. It is explained in several places -- [An Introduction to Petname Systems](http://www.skyhunter.com/marcs/petnames/IntroPetNames.html) +- [An Introduction to Petname Systems](petnames.html) - [Lambda for Humans: The PetName Markup Language](http://www.erights.org/elib/capability/pnml.html) Each identity, whether a human, a server, or something else, has a globally diff --git a/docs/names/zookos_triangle.svg b/docs/names/zookos_triangle.svg new file mode 100644 index 0000000..41e83ca --- /dev/null +++ b/docs/names/zookos_triangle.svg @@ -0,0 +1,87 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/docs/writing_and_editing_documentation.md b/docs/writing_and_editing_documentation.md index f523b24..fef0dc8 100644 --- a/docs/writing_and_editing_documentation.md +++ b/docs/writing_and_editing_documentation.md @@ -340,7 +340,16 @@ Alignments can be specified as with pipe tables, by putting colons at the bounda | Right | Left | Centered | +---------------+---------------+--------------------+ -# diagrams +# Images + +Images are preferably `*.webp`, and are expressed as the markdown code + +`![](./image_name.webp){style="width: 479px; height: 386px;"}` + +assuming the actual image size is 479 pixels wide and 386 pixels high, 479 pixels being the typical width of an image rendered at 100% of the text width with my default formats, and indeed a whole lot of other people's default formats on a typical screen. But obviously pixel size is getting smaller, so for device independence and simplicity, might well give a larger image, and leave out the style command. + + +# Diagrams The best way to do diagrams is svg and the Visual Studio Code scalable vector graphics extensions. @@ -374,8 +383,9 @@ that causes the least grief, and gives you a nice smooth curve. The first point is the starting position, the last point is the end position. The direction of the first control point sets the starting direction, the direction of the second control point sets the end -direction, and how far the control points are out controls how +direction, and how far the control points are out controls how and where the curve changes direction. If the curve is weird and pathological, there is something funny with your control points. + Some control point positions lead to singularities in the derivative of the curv but for reasonable control point positions, you get a nice smooth curve. @@ -396,14 +406,11 @@ curve, the further its influence propagates into the next S curve. Which can have surprising results if the next S curve is very short, so that influence of the previous control point propagates far beyond its end. -If you want a smooth and gentle curve, you want the last C or S -control point to be around the middle of the curve, and its -reflection in the next S curve to be around the middle of the next S curve +If you want a smooth and gentle curve, you want the the reflection of the previous C or S control around the middle of the next S curve You only need additional points when you want the curve to go through a narrow pass, in which case you are going to have a C -curve going to the narrow pass, and an S curve going to the -destination or the next narrow pass. +curve going to the narrow pass, the last control point before the narrow pass, its reflection in the next S curve after the narrow pass. When you want to join two points, and don't care about the path, use an L straight line @@ -448,15 +455,35 @@ the C to be in line with the last two points of the prior curve. M point q point point t point t point ... t point ``` -Is also guaranteed to give you a nice smooth curve for any -reasonably sane choice of the initial control point and the position -of the t points, but you cannot easily control the direction the curve -takes through the points. Changing the control point of the first q -will result in things snaking all down the line, and changing any of -the intermediate t points will change the the direction the curve -takes through all subsequent t points, sometimes pushing the curve -into pathological territory where bezier curves give unexpected and -nasty results. +
+ +
+ +```html +
+ + + + + +
+``` + +Is also guaranteed to give you a nice smooth curve for any reasonably sane +choice of the initial control point and the position of the t points, but you cannot easily control the direction the curve takes through the points. Changing the control point of the first q will result in things snaking all +down the line, and changing any of the intermediate t points will change +the the direction the curve takes through all subsequent t points, +sometimes pushing the curve into pathological territory where bezier +curves give unexpected and nasty results. Scalable vector graphics are dimensionless, and the `` tag's height, width, and ViewBox properties translate the dimensionless