The ".onion" Special-Use Domain Name
draft-ietf-dnsop-onion-tld-01

[Personally, I believe having the IETF assign TLDs is a very slippery slope.  Of course, given rfc6761, that boat seems to have already sailed.]

1. I know there’s an update to the Security Considerations in progress..but I would like to point out an additional item:

Section 2 (The ".onion" Special-Use Domain Name) says that "human users are expected to recognize .onion names as having different security properties”.  While Tor users may have no issues with recognizing the .onion names, I don’t think it is sensible to expect that the average Internet user will be able to clearly identify them as special, much less understand their properties.  Also, the Security Considerations section says that “users must take special precautions to ensure that the .onion name they are communicating with is correct”, but none of those precautions are mentioned, nor what “correct” means (specially in light of the fact that part of "a .onion name is not intended to be human-meaningful”).  I would like to see some text in the Security Considerations around the risks that the average user may face if using a .onion addresses (or something that looks like one) through their browser (for example) — I realize that won’t necessarily help the average user (who probably will never know this document even exists), but I think it is important to call out.


2. References.  Given that Section 2 (The ".onion" Special-Use Domain Name) says that "Resolvers MUST…respond to requests…by resolving them according to [tor-rendezvous]…” I think that reference should be normative.  The same for the main Tor reference [Dingledine2004], which builds the base of why these are special names.


3. Nit. Section 2 (The ".onion" Special-Use Domain Name)  s/either either/either

Quoting Alvara, whose opinion I share: " [Personally, I believe having the IETF assign TLDs is a very slippery slope. Of course, given rfc6761, that boat seems to have already sailed.]

Discussing this matter with Joel, one extra argument (not in the write-up) in favor of allocating .onion is that ICANN set this .onion TLD aside (flagged as problematic). So there is no monetized value for it.

If/Once [tor-rendezvous] is a normative reference, do we consider github as stable enough? What if that link disappears?

Nits/editorials (flagged by Tom Taylor's OPS directorate review)
    Section 2 item 3: s/either either/either/

I agree with Stephen's points that the long debate has utility and that there were some proposed text changes that appear to be missing.

Thanks for addressing the SecDir review comments (in progress, should be in next revision).
https://www.ietf.org/mail-archive/web/secdir/current/msg05876.html

I'm seeing a lot of discussion (even during IESG Evaluation) that resonates with me, but the people having that discussion are more clued about DNS and the policy thereof, than I am.

I do have one observation that I haven't seen anyone else touch on:

I thought .onion was tied closely to the TOR protocol, so I have no idea why the second sentence in this paragraph is here, or what it means, and neither the string "TOR" nor the string "onion" appear in RFC 7230, so chasing that reference didn't help.

   Like Top-Level Domain Names, .onion addresses can have an arbitrary
   number of subdomain components.  This information is not meaningful
   to the Tor protocol, but can be used in application protocols like
   HTTP [RFC7230].

Am I just being dense the night before a telechat, and everyone else understands what this means and why it needs to be included in this document? 

If this isn't clear to other people, could you either say more about what it means, or delete the second sentence?

I'm not confused about the first sentence, only the second ...