Skip to content

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):

  1. Allocate second-level domains atop of the existing .onion (RFC 7686), such as what happens with SecureDrop Onion Names (.securedrop.tor.onion).
  2. Use whichever TLD provided by each Onion Names solution.
  3. 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.

References:

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.

Stacks (former Blockstack)

Description

To be written.

Security Properties

To be evaluated.

Drawbacks

To be evaluated.

Kusama

Description

To be written.

Security Properties

To be evaluated.

Drawbacks

To be evaluated.

Unstoppable Domains

Description

To be written.

Security Properties

To be evaluated.

Drawbacks

To be evaluated.

Ethereum Name Service (ENS)

Description

To be written.

Security Properties

To be evaluated.

Drawbacks

To be evaluated.

CONIKS

Description

To be written.

Security Properties

To be evaluated.

Drawbacks

To be evaluated.

Handshake

Description

To be written.

Security Properties

To be evaluated.

Drawbacks

To be evaluated.

Oxen Name System (ONS)

Description

To be written.

Security Properties

To be evaluated.

Drawbacks

To be evaluated.

Dapp

Description

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

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?