The ".onion" Special-Use Domain Name
RFC 7686

Note: This ballot was opened for revision 00 and is now closed.

(Jari Arkko) (was Discuss) Yes

Comment (2015-09-03 for -00)
No email
send info
I would like the document to be approved, and recommend its approval with a Yes. Before that I wanted to have a brief discussion with the IESG if it would be useful to send a message to the community that we believe RFC 6761 needs to be open for review and modification, and that the current rules may be inadequate and unscalable.

The two last references need to be normative ones, I believe. I would like to suggest a note to the IETF list (if not already happened) that this is being changed and then approving the document.

Ben Campbell Yes

Comment (2015-09-01 for -00)
No email
send info
This one took some soul searching. But I think the arguments have been made, and that on the whole this registration does more good than harm.

I agree with the several people who have pointed out that [tor-rendezvous] should be a normative reference.

Nit: The abstract could use a bit more meat. For example, that the .onion special-purpose name is for use with Tor.

Alissa Cooper Yes

Comment (2015-08-31 for -00)
No email
send info
Registering this name seems warranted in light of the potential security impact. We need to make our processes work for the Internet, not vice versa.

I agree with Alvaro and Stephen's comments. In particular, to my eye [tor-rendezvous] should be a normative reference given item #3 in Section 2. However, it seems more important to publish this document than to re-issue the last call to call out a new downref.

(Stephen Farrell) Yes

Comment (2015-08-21 for -00)
No email
send info
(6 pages, so I read it now:-)

We definitely need to approve this. It's been too
long in the process already and that's been our
(the IETF's) fault. (I won't object to us trying to
improve 6761 after we've done this one, so some
of the long debate will have lasting utility.)

I thought I saw some edits from the last call
that were agreed to be applied and that would
improve the document. In particular, one that
was to the effect that .onion names would in
future need to conform to DNS name syntactic
constraints (lengths basically) so that if a
node did send a DNS query containing a .onion
name, that'd be less likely to cause weird 
issues.

Section 2 is a little sloppy in how it talks
about ".onion addresses (point 1), ".onion
names" (which is the right term I think) and
"queries for .onion" (I think you mean any
query for any .onion name and not only for
the TLD #4 and #5). A bit more consistency
would be no harm, though it's clear enough as
is.

(Joel Jaeggli) Yes

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Benoît Claise) No Objection

Comment (2015-09-03 for -00)
No email
send info
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/

Spencer Dawkins No Objection

Comment (2015-09-02 for -00)
No email
send info
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 ...

(Brian Haberman) No Objection

Comment (2015-08-28 for -00)
No email
send info
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.

(Kathleen Moriarty) No Objection

Comment (2015-08-31 for -00)
No email
send info
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

Alvaro Retana No Objection

Comment (2015-08-31 for -00)
No email
send info
[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

(Barry Leiba) Abstain

Comment (2015-09-01 for -00)
No email
send info
I believe the IETF shouldn't be involved with registering special-use TLDs for things that were used outside of IETF protocols, and should not be wading into territory that belongs to ICANN.  I know there are a bunch of other such TLDs that people/organizations would have us snag for them, and I very much want to avoid doing a batch of others.

That said, I well understand the deployed code involved and the importance of keeping things working in this case, and I don't want to stand in the way.  So I'm standing aside with an "Abstain" ballot.