[HN Gopher] Petnames: A humane approach to secure, decentralized...
___________________________________________________________________
Petnames: A humane approach to secure, decentralized naming
Author : todsacerdoti
Score : 64 points
Date : 2024-11-24 14:38 UTC (8 hours ago)
(HTM) web link (files.spritely.institute)
(TXT) w3m dump (files.spritely.institute)
| freeone3000 wrote:
| I propose an implementation of these petnames by sharing
| directory access through mutually trusted brokers, whose identity
| is proven by certificates and whose location is discovered
| through a standardized directory service protocol. I think we can
| make huge strides by working with the ITU here -- if we can
| convince them IP is the next big thing, then we might not end up
| being chained to the OSI netstack for the first release.
| lann wrote:
| Sarcastic replies can be fine. Sarcastic replies when you
| clearly didn't read the article are just annoying.
| freeone3000 wrote:
| It's proposing a decentralized naming scheme, with nearly
| zero implementation details, with the idea that it works like
| split-horizon dns plus some undefined form of list sharing.
| Adding a bunch of cryptographic stuff to it doesn't really
| change the hard bits of discovery.
| woodruffw wrote:
| There are some niceties here, but I think this is a little thin
| on the security aspects of the scheme: it's not clear how users
| establish the _authenticity_ of transitively received petnames,
| for example.
|
| More fundamentally, there's a factor outside of Zooko's triangle:
| trust isn't really transitive[1]. I trust my doctor and my doctor
| trusts their sibling, but I don't necessarily trust their
| sibling.
|
| With that being said, I think there's a pretty rich research
| space here, and I think the edge/local aspects of this design are
| pretty interesting! I just hope we don't end up with a
| reinvention of historically insufficient web-of-trust
| architectures :-)
|
| [1]:
| https://uhra.herts.ac.uk/bitstream/handle/2299/4349/904849.p...
| davexunit wrote:
| There's an associated paper that goes through implementing a
| petname system in a simple chat application. Petnames compose
| well with object capability security.
|
| https://files.spritely.institute/papers/implementation-of-pe...
| woodruffw wrote:
| That's great, but I don't think it addresses the basic point:
| sharing edge names requires a _way_ to share those names, and
| that 's a trusted third party (one with a degree of
| centralization, to boot).
|
| There are ways to (dis)intermediate that trust (like a PKI),
| but the shape of that PKI or other technique is itself a
| question of decentralization, security, etc. I think that's a
| _very hard_ underlying problem that the petname design needs
| to at least offer some opinions on in order to make claims
| about security.
| paroneayea wrote:
| Jessica Tallon's implementation of petnames and edge names
| was extremely simple within the paper davexunit linked, but
| used in-band mechanisms to communicate edge names that
| didn't require any sort of large trusted authority. You
| could retrieve them directly from fellow peers, who could
| publish their current set of edge names. This even works in
| a p2p context over ocapn, etc. The implementation was naive
| but it did work and used a publish-subscribe mechanism
| directly from other peers.
|
| That said, edge names are only one way to share contacts.
| In fact "share contact" on peoples' phones is a great way
| to have contextual sharing: "Oh, let me introduce you to my
| friend Dave. Here's Dave's contact info!"
|
| At any rate, petnames aren't a particular technology,
| they're a design space of "Secure UI/UX". However I do
| agree more research needs to be done in that space; we've
| only barely begun to scratch the surface.
| catlifeonmars wrote:
| > trust isn't really transitive
|
| Not sure I agree with this. Sure, trust might drop off pretty
| quickly (like an inverse square law), but I would still trust a
| friend of a friend over a complete stranger.
| woodruffw wrote:
| I would also trust a mutual friend over a complete stranger.
| But that's not the point of the observation: the observation
| is that "trust" isn't a boolean, but an umbrella term for a
| wide range of policies that we apply to different principals.
|
| Or in other words: transitive trust is a thing, but it's of a
| different color than "trust." Attempts to gloss over this in
| web-of-trust designs have historically not gone well.
| mglvsky wrote:
| I have crazy idea to produce mnemonic rules for every DID, maybe
| fancy-AI tech would help
| sneak wrote:
| I think perhaps the PoW/PoS solution to byzantine generals (as
| used by Ethereum, for example) can and does solve the Zooko's
| triangle problem via things like ENS.
|
| I don't anticipate that end users will be able to ingest or cope
| with the mental model involved with the correct usage of the
| system described in TFA.
| fanf2 wrote:
| I have long been a fan of petnames, and graph naming systems in
| general.
|
| I like to use the term "nickname" for what they call "edge names"
| in the article: a nickname is not as personal as a petname, it's
| a name you share with others.
|
| An interesting thing that the article sort of hints at is that
| these kinds of systems have a fairly smooth range of operating
| points between globally unique and centralized vs decentralized
| petnames. The article's example of the bizdir local business
| directory is somewhere in between these extremes. It sort of
| turns Zooko's triangle into more like a fan, where the "human
| friendly" point is fixed and there's an arc describing the
| tradeoffs, from personal through local to global.
|
| How can a petname system function at the global+centralized
| point, so it could replace the DNS? It needs to pass the
| "billboard test": I type in a name I saw on a billboard and I get
| to the right place. (It might be a multipart name like a postal
| address or DNS name, with an extra "edge name" or two to provide
| enough disambiguating context.) I imagine that an operating
| system supplier might provide a few preconfigured petnames (well,
| it probably includes its own petname so the software can update
| itself securely), a lot like its preconfigured PKIX CA
| certificates. These petnames would refer to orgs like the
| "bizdir", or Verisign, or Nominet, that act as nickname
| registries. Your collection of petnames is in effect your
| personal root zone, and the preconfigured petnames are in effect
| the default TLDs. There would inevitably be something like the
| CA/Browser forum to mediate between OS suppliers and nickname
| registries: a petname ICANN.
|
| I wrote an older iteration of these ideas over a decade ago
| (https://dotat.at/@/2012-02-28-path-names-in-a-rootless-
| dns.h...). Those notes have a bit too much DNS braindamage, but I
| included some curious anti-DNS discussion: How you might make use
| of reaching names by multiple paths? What might it look like to
| have a shared context for names that is not global but is
| national or regional or local?
___________________________________________________________________
(page generated 2024-11-24 23:00 UTC)