Petnames: A humane approach to secure, decentralized naming
33 points by veqq
33 points by veqq
Self-proposed names are kinda funny in that it’s not always clear who gets to see it. I’ve seen (internally) all sorts of Preferred Names, from the usual “(Victoria => ) Vicky” to “… Darth Vader” to “8=====D - - “ &c &c.
Also I know I’m not the only one with, how do you say, Olde English names in my phone like “Mark Neighbor”, “Eddie Maintenance”, “John HVAC” that I don’t know I would share. Perhaps.
Discussed previously (8 comments): https://lobste.rs/s/r2m7s2/petnames_humane_approach_secure
Strange that it wasn’t flagged (it’s the same url). Trying to submit again, only this current story comes up - this one is listed on the older one (but the older one isn’t listed on this newer one either!) I’ll make a bug report.
It is a known bug.
Looking at the GH issues seems to point to this one
https://github.com/lobsters/lobsters/issues/1529
I’ve added a comment there about what I’ve observed here.
“ The most popular contemporary naming systems on the internet today are not only centralized but also vulnerable to phishing attacks. “
I’m not getting how petnames would solve the phishing part. Yeah, you could have “DomainSpace ⇒ paypa1.com” automatically redirects to “DomainSpace ⇒ paypal.com”, but what about “ᎠomainSpace ⇒ paypal.com” ? (if you don’t see any difference, the Ꭰ from ᎠomainSpace is a CHEROKEE LETTER A character).
You would kind of need a source of trust for the naming hub part (maybe I’m missing something).
You create petnames yourself. Either you make one up, or you implicitly create it by adding the address to an address card in a contacts app.
It’s also possible for the system to use your contacts’ petnames, like naming an address “steve->martha” if your petname “steve” has a public petname “martha” for this address. But again, you probably trust steve not to play weird phishing games; and if not, it’ll be clear this isn’t a martha you know directly.
(In the prototype I built, your direct petnames are visually highlighted differently than regular text or transitive names, and in a way that can’t be faked.)
Petnames defines various different kinds of names, the petname steve->martha would be an “edge name” according to the petnames doc, which isn’t by itself useful, in order to resolve it you’d first have to resolve steve to a specific ID in the underlying system you use for globally-unique and decentralized IDs, which is based on a mapping for steve that’s defined in your user-local petnames DB, which is guaranteed to be valid but isn’t guaranteed to be up-to-date. OK, knowing that, you make the resolve to some ID, then you next have to use that resolved ID for steve to fetch steve’s set of published contacts, from some other third-party system containing everyone’s petnames DBs, which you must implicitly trust, and must be implicitly shared, and to which you supply a query lookup ID for steve that must include some kind of SHA representing the version of steve’s contacts that you’re using locally. that fetched data for steve’s petnames is gonna have some version/SHA, which is gonna be verifiably something that steve published at some point in time, but cannot be assumed to be up-to-date, and may or may not include a mapping of martha to a unique ID. so really steve->martha doesn’t work as an edge name, at a minimum you’d need to say steve@SHA->martha, which guarantees validity but not correctness, so even if you did that you can’t trust it to be the same notion of ‘steve->martha’ that steve said when he spoke to you 30s ago, at least not unless that conversation was verified such that steve published his current assumed version/SHA and you only accepted the connection if you verified that SHA was the same as the SHA of steve’s contacts as you had them in your local petnames db. and that’s just one of many ambiguities that aren’t covered by the petnames doc, and make it difficult for me to understand how petnames makes sense? If I’m misunderstanding something I’m all ears and happy to be better informed!
I read the petnames papers more than a decade ago, and heavily internalized them into my own designs, so I’m probably not defining everything the way they do.
To me, petnames is a PKI system (see also: SDSI, SPKI). Identities are public keys. Your local petname dictionary maps names to public keys. Principals can publish dictionaries of the name mappings they want to be publicly known. (Ideally you can also publish non-public dictionaries that only selected people can decrypt and read.) All of these are of course signed.
As I’ve implemented it, there is no central anything; data is propagated P2P. If steve is a contact of mine I’m subscribed to his “feed”, so his contact list is up to date.
As I’ve implemented it, there is no central anything; data is propagated P2P. If steve is a contact of mine I’m subscribed to his “feed”, so his contact list is up to date.
That’s not strictly-speaking true. By subscribing to Steve’s feed, you’re getting some verified version of his contacts, but that doesn’t mean that it’s up-to-date. Steve can change his local Terry from ID1 to ID2, and if for any reason publishing that update takes a long time or fails, then your version of Steve’s contact list is not the same as Steve’s version of his contact list. In that case if Steve says “talk to Terry” he means ID2, but when you resolve “Steve’s contact Terry” you’ll see ID1. “Steve’s contact Terry” is ambiguous, to fix that ambiguity it would need to be “Steve@SHA’s contact Terry” which is of course no longer human-readable and therefore kind of subverts the whole purpose of the thing.
There is no such thing as simultaneity, or a consistent ordering of events, in a distributed system. You’re describing the sort of race condition that can happen. But the message I’m reading from steve probably predates his updating his address book [would have to, in my system] so it’s fine that it refers to the earlier Terry.
There is no such thing as simultaneity, or a consistent ordering of events, in a distributed system. You’re describing the sort of race condition that can happen
Sure, and yes.
But the message I’m reading from steve probably predates his updating his address book
The situation here is that Steve has updated his local address book to change Terry from ID1 to ID2, which is a change he makes and sees locally, but which has not yet been published in a way that you can fetch and update your local copy of Steve’s address book with. And that Steve calls you up in this intermediate state, and says “Talk to Terry”, by which he means ID2, not ID1. So the message you get from Steve is after he’s updated his local address book, and before you’ve seen that update.
[would have to, in my system]
This would mean that Steve, at address book version 2, can’t actually send you a message, until you’ve been able to fetch Steve’s address book at version 2 from his source-of-truth. That would make the system essentially unusable: Steve would be unable to send anything to anyone that hadn’t synced with his latest contact database, and identifiers would only be meaningfully defined within this (infeasible) system, i.e. they couldn’t be spoken over a phone conversation. Ignoring those things, it would also mean that the ID can’t be an unqualified pair of identifiers “Steve’s contact Terry”, but would need to be exactly what I said previously, “Steve@SHA’s contact Terry”, or in this case “Steve@v2’s contact Terry”.
This is basically tilting at windmills, but I hope it’s clear that petnames doesn’t solve what it says it solves.
That would make the system essentially unusable: Steve would be unable to send anything to anyone that hadn’t synced with his latest contact database
I don’t see how this is the case. In the simple case, when Steve sends you a message referring to Terry, he doesn’t send you his petname for Terry and expect you to do a lookup in his contacts. He sends you the external identifier for Terry that the petname refers to (let’s say a DID, since it was the example given in the article). Steve’s software might also include his petname for Terry in the message as a hint (though it doesn’t have to) but the external identifier is usable with or without a petname.
I don’t see how this is the case. In the simple case, when Steve sends you a message referring to Terry, he doesn’t send you his petname for Terry and expect you to do a lookup in his contacts.
This is more or less exactly what the first example in the petnames paper describes as a use case. Alyssa is speaking to Dr. Nym on the phone and speaks the name “Ben” aloud, and then Dr. Nym types in “Ben” to her phone’s contact list, which returns a contact named “Alyssa -> Ben” – which is what petnames calls an “edge name”, and represents the petname Ben, as defined by Alyssa, in some prior version of Alyssa’s published contact list, which Dr. Nym has a copy of.
Okay, I’ll grant you that; I’d forgotten that the paper used a phone call as an example. It’s not the only way to communicate in a petname system, but yes: if you’re speaking to someone aloud on the phone (and if we’re assuming PSTN rather than a petname-aware VoIP system that might let you select contacts to send during a call), the ability to look up edge names is crucial, because of course you’re not going to speak e.g. a cryptographic identifier out loud.
But in many cases the ambiguity resulting from this is fine. If I have an entry for Ben Bitdiddle in my contact list, I’m not regularly changing that entry to point to different people. That would confuse me too!
If it’s truly important to avoid any ambiguity, or if Dr. Nym can’t find Ben through edge names, she can ask you who you mean by that, and you can send the external identifier. Note that ideally your messaging software makes it possible to do this without directly displaying the external identifier, so you see something like: “Oh, sure, I meant [Ben Bitdiddle]”, and Dr. Nym sees “Oh sure, I meant [?Ben Bitdiddle]” (to use the proposed name syntax from later in the paper). The external identifier is being used there, but the software’s hiding it from you, because to quote the paper:
“If we ever show a DID to a user we have failed.”
DomainSpace would be a name local to you, not a global name, so there’s no phishing concern there. After all, we don’t worry about phishing in our phone’s contact list - we put those contacts there!
This does indeed mean that you need an initial bootstrap reference to someone in the naming system, though you can imagine that e.g. an Android phone using a petname system might come with a petname for Google preloaded. (Adding another could be a matter of scanning a QR code from someone you trust, if you’re starting from zero.)
After all, we don’t worry about phishing in our phone’s contact list - we put those contacts there!
People who discuss foreign invasions over Signal would disagree with you here.
That would imply a certain level of self- and/or security awareness on the part of said people, though…
Facepalms aside, I think it’s a fair point that somebody could impersonate a known contact. On the face of it, it seems like a more targeted/spear-phishing approach but given predictable names isn’t hard to implement. I would go as far as to say it doesn’t even require 100% accuracy if an attacker is willing to “spray and pray”.
I’ve certainly received phishing emails claiming to be from people who are part of my social media circles, so such attacks are already out there in the wild.
I think it’s a fair point that somebody could impersonate a known contact.
The point of a petname is that it is a locally-assigned human-readable alias for a public key. In a petname system it should be hard to impersonate a known contact because the attacker’s key won’t match so their claimed name will be adjusted to make it distinct. (But it has to be resilient enough to avoid the human factors issue of an attacker claiming to be a friend in trouble who lost their phone and is using a fresh key.)