The “.onion” Special-Use Domain Name (2015)

https://tools.ietf.org/html/rfc7686

by franze • 10 years ago

180 67 10 years ago

tools.ietf.org

hackuser• 10 years ago

From 2015

superkuh• 10 years ago

Yep. The author, Appelbaum, is no longer with Tor after falling victim to one of the many successful culture-based attacks on privacy and free software groups in 2015/2016.

nerdponx3• 10 years ago

You're gonna have to explain that a little.

gohrt• 10 years ago

They were attacks on violations of the community's sexual morality, not attacks on privacy and free software.

stretchwithme• 10 years ago

I thought for sure that was going to be a TLD devoted to satire :-)

johnhenry• 10 years ago

In some ways, it is...

prewett• 10 years ago

I figured "special-use" meant that only one domain name would be valid. Namely, "the".

cmrx643• 10 years ago

I'm curious why they decided on a "special-use domain name" instead of something like "onion://hash".

eriknstr2• 10 years ago

It was a long time ago that TOR chose to do so. I also think TLD makes sense anyway. TOR is a network and the protocol of the traffic that is relayed through it is independent of the transport.

vortico2• 10 years ago

This committee recognizes what already exists. onion://hash is not used because .onion domains are not different protocols (they're still http) but are a specially allocated space of hostnames representing the "addresses" of Tor servers.

niij• 10 years ago

.onion domains can use any service they like and are not limited to just HTTP.

These are all valid: ssh://abc123.onion ftp://abc123.onion https://abc123.onion

AgentME• 10 years ago

Onion addresses describe a host that can be talked to via TCP, not just HTTP.

zrm2• 10 years ago

Because https://*.onion and ftps://*.onion are different. And it lets you do things like tor2web by just appending a DNS domain to the end of the onion domain, without requiring any special client support. And more things break on unexpected protocols than unexpected names.

cmrx643• 10 years ago

That makes sense. I wasn't aware of the details, but looking into it now, "onion"/hidden services are a way of establishing tor circuits which are then used normally. Thanks!

greglindahl• 10 years ago

*.onion.link is an example of tor2web

NL807• 10 years ago

Two URL schemas could've been easily specified to accommodate the two scenarios: httpo://... and ftpo://...

kaoD• 10 years ago

Maybe https+onion://, ftps+onion://, etc.? .onion being a special-cased TLD is calling for unexpected privacy leaks.

chungy2• 10 years ago

It is extremely useful for an onion address to just define a plain old TCP socket, rather than imply HTTP. An onion address is just that... an anonymous connection to some server, somewhere in the world. While you might be unaware of where the service is operated from, it could be the exact opposite: maybe you just started an ssh server on your desktop and would like to access it remotely where ssh might be monitored or blocked -- despite ssh itself being encrypted, making a connection and the lifespan of the connection tell quite a lot about your habits. Or maybe you decide to visit China for a weekend... Hell, or maybe you're buried behind multiple NATs/firewalls and just need an easy way to poke from the outside (I've done this, in corporate environments where you can run your own VMs and such)

cmrx643• 10 years ago

I'm not sure why so many people seem to think that I'm implying anything about HTTP. "onion" would be fine as a URI scheme I think. Different programs would interpret it differently, which is obviously bad, and using a special-use domain name lets it slot seamlessly into the usual URI system as just a different sort of host specifier, which is obviously better, lacking something like nested URIs (http://www.it.uc3m.es/muruenya/papers/nested_uris_euromicro0...), which never became a thing.

eriknstr2• 10 years ago

About time (even though it was in 2015). I was afraid that someone was going to buy .onion and use it to deanonymize people who thought they were on TOR when they were not.

vortico2• 10 years ago

THIS is the important point of this post. It might be "cool" that they now recognize the TLD now, but I can't imagine the chaos it would cause if .onion was purchased.

sandworm101• 10 years ago

There were plans for that contigency. Tor would have moved to some other tld (ie .onionland). The tor browser bundle would update bookmarks and probably issue a warning for .onion addresses. Annoyance but not chaos.

agildehaus• 10 years ago

Many web browsers have predictive services built-in to the address bar. Some are even enabled by default. Google has undoubtedly seen .onion addresses submitted.

chungy2• 10 years ago

This is why the Tor Browser is a thing.

rektide• 10 years ago

FWIW this came after a long long period of the DNSOP working group throwing hate and venom on this form of hithertofore non-normative DNS use cases. This was a very hot topic and it seemed like absolutely no progress was going to be made making this happen for a long time due to the DNSOPS wg.

I don't have good citations- would love to gather them again- but it was only after other IETF members started questioning the absurd rejectionist behavior of the DNSOP working group that this changed, and the .onion draft was allowed to get due status.

I can't think of any case in IETF history of a draft being so hotly denied and rejected. Very interesting story, look forward to someone telling it better than I.

wereHamster• 10 years ago

Who are the people in the DNSOP WG? Which companies do they work for? And why do these companies reject the RFC?

nl• 10 years ago

Much of the time the people on IETF WGs have been on them for years through multiple companies. There are exceptions, but often this rejectionist-type behavior isn't because of some kind of corporate influence, it is because the new thing doesn't match what these people think should be done.

mastax• 10 years ago

I don't have good citations- would love to gather them again

Here's a good place to start for anyone interested:

https://mailarchive.ietf.org/arch/search/?email_list=dnsop&q...

chatmasta• 10 years ago

Man, sometimes I wonder if in 20-30 years there will be anyone left who is this passionate about such seemingly obscure topics. The Internet owes much of its success to these people.

canndrew20162• 10 years ago

Also, they were originally trying to get several already-in-use psuedo-TLDs recognized including .onion, .i2p, .bit and .gns, but they had to compromise.

Tepix• 10 years ago

Is someone working on getting .bit officially recognized by the IETF?

nerdponx3• 10 years ago

What is .bit?

TeMPOraL• 10 years ago

  Applications that do not implement the Tor
  protocol SHOULD generate an error upon the use of .onion and
  SHOULD NOT perform a DNS lookup.

Wait, does this mean that all my applications that deal with URLs now have to check for and reject entries that use .onion domain?

Jarwain• 10 years ago

I'd think, for the most part, it would act like using a typical invalid URL and throw an error. Special cases would be, say, Chrome rejecting .onions instead of doing a search

jdiez17• 10 years ago

Only applications that actually access URLs would need to generate an error. In practice, your code doesn't need to know about .onion domains - but network libraries like libcurl do.

andreareina• 10 years ago

Abstractly something on layer 7 of the OSI model shouldn't care exactly how the data is being routed, but the security considerations of using TOR breaks the abstraction. A naïve client could be made to leak identifying information through any number of side-channels. Since the lower layers can't have a whitelist of acceptable applications to connect to .onion addresses, the applications themselves must voluntarily refrain from connecting.

This is like the prevailing wisdom to check malloc's return value, not storing passwords in the database, not rolling your own crypto, etc. except that in this case it actually got included in the standard. Unfortunately like all those other things, there's nothing that actually prevents a programmer from breaking the rules.

jstanley• 10 years ago

You don't have to.

The reason to do so is to protect your user's privacy (i.e. so that their DNS server doesn't see what onion addresses they were trying to visit).

dheera• 10 years ago

What is this nonsense? A domain iooks up to an IP address (and some other things). DNS does not and should not care about what protocols are going to be used with said IP address.

I can use an .onion domain for unencrypted Telnet as root with no password if I want. It's stupid but that's not something that should be restricted at a DNS level.

erydo• 10 years ago

At first I agreed with you, but realized that my preferred solution was essentially what they recommended and just with different wording. My thought process was:

  - Absolutely, DNS resolvers should not care or have knowledge of the protocol that will be used to access that address.
  - What they *should* do is just say that normal DNS resolvers shouldn't ever resolve .onion addresses.
  - (And then Tor should include a special DNS resolver that does anyway.)
  - Oh, that's compatible with what they said.

I think some of the confusion comes from their use of "applications".

avar• 10 years ago

Relevant: A draft RFC for an X.alt tld, so in the future the next thing like the next X.onion would be X.onion.alt instead, with X.oninon not expected to change due to backwards compatibility: https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-00

wccrawford• 10 years ago

The idea that we're treating name resolution differently by different applications is... Crazy. I can't even begin to imagine all the ways that is going to fail.

The idea that users would have to be careful not to enter a .onion domain into non-TOR software is also crazy. Of course they're going to do this, and they're going to do it often.

And relying on applications not to asking publicly for resolution for .onion domains is laughable. It's going to happen a lot.

As others have noted, they should have implemented new protocol names instead. All existing software that doesn't follow these rules would simply do nothing (or return an error, as is appropriate) and only applications with actual support would attempt to do anything.

AndyMcConachie• 10 years ago

A couple of things you may be interested in reading.

http://www.verisign.com/assets/labs/Measuring-the-Leakage-of...

https://www.icann.org/en/system/files/files/sac-090-en.pdf

belorn• 10 years ago

There exist several other and older top level domains which should never be publicly resolved. .localhost, .example, .invalid, and .test are a few domains which most resolvers (and even operative systems) know to not try resolve. .local, is an new one which zeroconf is primary responsible to resolve.

To go to the extreme of having no such reserved domains would be crazy and way too much existing software would break spectacularly if anyone tried. rfc6761 is simply an update to rfc2606, by extending the concept of the reserved names like .localhost to names like .local or .onion.

drvdevd• 10 years ago

Of course this sounds like the right engineering approach, but perhaps fitting that into the browser use case was not possible in a manner suitable for the Tor project? After all, the primary interface to the Tor network for most users is their browser.

[edit] meant to add: of course you could add a new protocol, but then that would imply browser modifications, right?

robert_foss2• 10 years ago

Bundled with the .onion application was originally .i2p and .gnu applications as well.

Only after the Tor project unbundled the non .onion TLDs was any progress made.

After the .onion TLD had been accepted the process by which these special (reserved TLDs) were registered at the IETF was removed. The IETF bent over backwards not to include anyone and when they did they only allowed for a single TLD to be reserved before closing the special (reserved) TLD application process. Mind you that .gnu and .i2p applied on the exact same grounds and even on the exact same application originally.

I have never been in contact with a more dysfunctional and bureaucratic organization.

nerdponx3• 10 years ago

Why are they so hostile to these requests?

gulaschbrot• 10 years ago

I guess because you cannot make money selling reserved special use domain names.

robert_foss2• 10 years ago

I can't tell you why, but I suspect a reluctance to do anything new.

hobarrera• 10 years ago

This is really cool, and I really hope that resolvers adopt this --- which basically means dropping any queries for `.onion` to avoid leaking that a client attempted to resolve such a domain.

The “.onion” Special-Use Domain Name (2015)

Related Stories