Onion Names¶

About¶

Onion Names are human-memorable mappings to Onion Service addresses. Apart from traditional DNS-based domains, Onion Names may be provided by different systems, taking into account that:

There may be no ideal solution, so the question is which are acceptable solutions that can coexist.
Each solution needs to have it's own namespace.
Each implementation can have an it's own adoption cycle (proposal, evaluation etc).
Each solution category/technology (ruleset-based, blockchain-based etc) can also have it's own discussion criteria for evaluating proposals.

Namespace allocation¶

Regarding namespace allocation, there are many possible options, including (but not limiting to):

Allocate second-level domains atop of the existing .onion (RFC 7686), such as what happens with SecureDrop Onion Names (.securedrop.tor.onion).
Use whichever TLD provided by each Onion Names solution.
Use a second-level domains atop of the proposed .alt top-level (draft-ietf-dnsop-alt-tld-08).

There are discussions about whether Onion Names should all be under .onion or have their own namespaces, especially considering draft-ietf-dnsop-sutld-ps-03, RFC 7686 and other documents specifying what's officially supported by internet standard bodies such as IETF and IANA.

In the scope of Proposal 279, for instance, it's possible to imagine a scenario where official allocation happens as second-level namespaces of .onion, while other namespaces could be manually configured by users.

Overview¶

Method	Technology	Existing namespaces	Status
Onion Names for Securedrop	Ruleset	.securedrop.tor.onion	Implemented, officially supported
Namecoin	Blockchain	.bit	Development
Dappy	Blockchain	.d	Research
Stacks	Blockchain	?	Research
Kusama	Blockchain	?	Research
Unstoppable Domains	Blockchain	.crypto .nft .x .wallet .bitcoin .dao .888 .zil .blockchain	Research
Ethereum Name Service	Blockchain	.eth	Research
Handshake	Blockchain	-	Research
Oxen Name System	Blockchain	?	Research
Dapp	Blockchain	.dapp	Research
GNU Name System	P2P	.gns	Research
IPFS	P2P	?	Research
OnioNS	Other	.tor?	Research
OnioDNS	Other	.o	Research
Dirauth-based	Other	?	Research
File-based	Other	-	Research
Tor Browser addon	Other	-	Research

Ruleset-based¶

Ruleset-based Onion Names depends on trust, which is delegated in that namespace to the organization managing the ruleset.
Criteria about who controls each ruleset can be:
User-based: equivalent to sharing bookmarks. Trust the authors. But how to assign namespaces?
Organization/federation based: like SecureDrop: list instances from a widely known and relevant platform. Trust the organization. How could be a criteria and process for a widely known and relevant organization to have it's ruleset namespace?

Onion Names for SecureDrop¶

Onion Names for SecureDrop. is the first implementation of a ruleset-based approach and is maintained by SecureDrop.

It's limited in the namespace it can use, so it does not conflict with other discovery methods.

It was originally implemented using HTTPS-Everywhere, and since mid-2022 it's is integrated in Tor Browser core and there's a proposal to edit (and maybe share) rulesets directly in the Tor Browser interface.

The rulesets are maintained in this repository.

User-supplied petnames¶

Another proposal for rulesets is to rely on user-supplied petnames instead of onion addresses in URL bar.

Blockchain-based¶

Namecoin¶

Namecoin is a fork of Bitcoin:

Description¶

Namecoin holds names in a blockchain. Name registration costs a virtual unit, denominated in namecoins.

Security Properties¶

Privacy-enhanced queries: full-node clients and FBR-C clients (full block receive for current registrations) do not generate network traffic on lookups
Globally unique names
Backed by computational proof-of-work
Purely distributed control of names (does not rely on Tor directory authorities or Tor relays)
Authenticated denial-of-existence for full-node clients and FBR-C clients (full block receive for current registrations).

Drawbacks¶

It is non-trivial to anonymously acquire Namecoins, which reduces the privacy of domain registration.
Registrations are only pseudonymous unless Namecoin is used in conjunction with an anonymous blockchain such as Monero; decentralized exchanges between Monero and Namecoin are not yet deployed, so Monero to Namecoin exchanges require some counterparty risk.
Full-node clients must download the blockchain, which may be impractical for some users, and becomes less usable as transaction volume increases.
No authenticated denial-of-existence for clients that only download block headers (this can be fixed with a future softfork).
Doesn't scale: it grows more secure but less usable as it becomes more popular.

Dappy¶

Description¶

To be written.

Security Properties¶

To be evaluated.

Drawbacks¶

To be evaluated.

To be written.

Security Properties¶

To be evaluated.

Drawbacks¶

To be evaluated.

Based on other technologies¶

The GNU Name System (GNS)¶

Description¶

GNS uses a hierarchical system of directed graphs. Each user is node in the graph and they manage their own zone:

Security Properties¶

Peer-to-peer design.
Individuals are in charge of name management.
Resistant to large-scale Sybil attack.
Resistant to large-scale computational attack.

Drawbacks¶

No guarantee that names are globally unique.
Difficult to choose a trustworthy zone.
The selection of a trustworthy zone centralizes the system.

InterPlanetary Naming System¶

Description¶

A naming system for IPFS. Can suit for .onion too.

Security Properties¶

To be evaluated.

Drawbacks¶

To be evaluated.

OnioNS¶

The Onion Name System, a New DNS for Tor Onion Services:

Description¶

OnioNS, pronounced "onions", is a privacy-enhanced and metadata-free DNS for Tor onion services. It is also backwards-compatible with traditional .onion addresses, does not require any modifications to the Tor binary or network, and there are no central authorities in charge of the domain names. OnioNS was specifically engineered to solve the usability problem with onion services.

This project was described in the paper "The Onion Name System: Tor-Powered Decentralized DNS for Tor Onion Services", which was accepted into PoPETS 2017. OnioNS also supports load-balancing at a name level. Development currently takes place on Github.

Security Properties¶

Anonymous registrations - OpenPGP key is optional, no personal information required.
Privacy-enhanced queries - uses 6-hop circuits.
Strong integrity - server responses are verified with a Merkle tree.
Decentralized control - a random set of 127 periodically-rotating Tor nodes manage names and publishes the Merkle tree root.
Globally-unique domain names with consistent mappings.
Support for authenticated denial-of-existence responses.
Server-server communication uses circuits.
Preloaded with reserved names to avoid phishing attacks.
Uses the latest block in Bitcoin as a CSPRNG.
Resistant to Sybil attacks.
Resistant to computational attacks.

Drawbacks¶

Users must install the software into the Tor Browser.
Requires participation from Tor relay administrators.
Users must trust a selection of Tor relays, Tor directory authorities, and Bitcoin during a query.

OnionDNS¶

OnionDNS: A Seizure-Resistant Top-Level Domain (DOI).

Description¶

To be written.

Security Properties¶

To be evaluated.

Drawbacks¶

To be evaluated.

Centralized first-come-first-served name cache run by a dirauth¶

Description¶

Just run a NamingAuth on the network where HSes can go and register their names. Clients can query the NamingAuth direct, and can also add alternative naming auths.

A bit like the I2P naming system?

Security Properties¶

Simple and easy.

Drawbacks¶

Centralized

Files with aliases¶

Description¶

Just hosts-like files with pairs <human-readable name> <identifier>. Widespread in I2P.

Security Properties¶

Simple.
Name resolution is done locally.

Drawbacks¶

Centralized.
Latent.
Involves trust to everyone involved in list making.
Markable. Malicious service can give different users different aliases.

Tor Browser addon for .onion bookmarks¶

Description¶

Basically introduce the workflow where our users are supposed to bookmark their onions so that they remember them next time.

A smart addon here could do it automatically for the users, or something.

Security Properties¶

To be evaluated.

Drawbacks¶

Need to keep list (or hashes) of visited onions on the client's machine.

Human Friendly Memorable Mappings¶

Description¶

This approach is currently just a few ideas in how to encode .onion addresses using symbols that are easier to memorize:

Whole phrases as checksums?
Generating images from the addresses? With an algorithm with special statistical properties to ensure acceptable security (like enough variance in the generated images).
Checksums used together with vanity addresses? So people could memorize just the checksum and the vanity portion of the address, like a sequence of emojis plus a 6 to 8 chars word. In that case, how long should be the emoji sequence?

Security Properties¶

Far from being used to show a limitation in the Onion Service technology, the difficulty to represent an .onion address in a human-friendly way could actually show it's strength.

We can compare the Onion Service address space, or just the "Onion Space", with other addressing systems, applications and mappings.

The following table is a rough sketch that attempts to summarize some "human-friendly mappings" and it's applications:

Applications	Address space size	Example mapping type	Example mapping size	Collision-resistance
IPv4, Tor bridge lines	32 bits	Symbols/Emojis	4	Total with enough symbols/emojis
Geocoding	~48 bits (?)	Base32	9	Fails for nearby addresses
Geocoding	~48 bits (?)	Word tuples	3 - 5	Fails for nearby addresses
Tor Onion Services v2	80 bits	?	?	?
IPv6	128 bits	?	?	?
Tor Onion Services v3	~256 bits	?	?	?

Space size:

Mapping size refers to the number of elements in the symbol space needed to represent (or to be a sufficiently secure checksum for) an address.
Emojis currently falls in the 32 bit space range (smaller than "street space" addressing, i.e, it's a space smaller than our geographic space); emojis can in theory be used to represent (or summarize) longer sequences, but that depends on both the emoji set size and the maximum length an average user could memorize.
Base32 and word tuples are useful for representing geographic locations in a small string, such as an URL parameter. They can be human-memorable if the coordinates aren't too precise.
We don't have anything (as far as I'm aware) from Onion Services v2 onwards. I've heard about some people memorizing .onion v2 addresses, but that's not a comfortable thing to do for everyone.
The Onionspace is way bigger than the IPv6 space, so why it's a hard problem to create a human-memorable "checksum" or alias!

Onion Names versus other mappings:

If the human friendly mapping fully represents (i.e. unambiguously, uniquely) the address, it's basically equivalent with an Onion Name (of the same size?), and effectively works as an alias to that address. In that case, the Onion Name has an advantage over other mappings since it can have a meaning related to the Onion Service purpose.
But if the mapping only partially represents the address, it works mainly as a "checksum", and that case the mapping is not collision-resistant, as it's possible to find two or more addresses having the same mapping.

Collision-resistance:

For geocoding, collisions depends on the grid resolution when it's done as a mapping over a discrete grid. Depending on the grid partition algorithm and the resolution in use, points in the surface of earth that are close enough to each other tend to have similar (or even the same) representation.

Drawbacks¶

This needs further research, to answer questions such as:

What is the length range (and symbol space size) to consider as inside the "human friendly" region?