[tor-dev] Registering special-use domain names of peer-to-peer name systems with IETF
mail at johnbond.org
Thu Feb 20 21:11:19 UTC 2014
Thanks for your response. This is very helpful and somewhat in line with
my expectations. I will forward this thread to the IETF list, please let
me know if there is more to add.
From: Nick Mathewson <nickm at alum.mit.edu>
Reply-To: <tor-dev at lists.torproject.org>
Date: Sunday 16 February 2014 03:51
To: <tor-dev at lists.torproject.org>
Subject: Re: [tor-dev] Registering special-use domain names of
peer-to-peer name systems with IETF
>On Thu, Feb 13, 2014 at 9:06 AM, John Bond <mail at johnbond.org> wrote:
>> Hello All,
>> Im writing to the list in response to IETF submission made by christian.
>Hi, John! This deserves a much longer response than I can give it
>right now. (I'm getting ready to head to Iceland for the developers
>meeting next week.) But let me see what I can figure out today, under
>the theory that a prompt reply is often better than a perfect one.
>> This has created much debate on the DNSOPS mailing list and has also
>> seen another draft to be proposed. I will start by saying I see
>> in both drafts being proposed and don¹t necessarily see them as
>> being mutually exclusive. However the discussions on the list seem to
>> keep coming back to one question would it be feasible for you to
>> retrospectively change the anchor of .onion to some other TLD. E.g.
>> .onion.arpa. There is much speculation on this questions however it
>> appears that the question has not been directly asked on this list.
>> Therefore I would like to ask the following.
>> - What would be the barriers both, technical and political, for tor to
>> change the anchor it uses from .onion to something else (whatever that
>Technically, we'd need to add the new address type as a supported
>address type, and then, after a year or three, we'd have to stop
>supporting the old type. I imagine we'd want to do a coordinated,
>flag-day style transition, because otherwise we'd run into problems
>with the new addresses not getting intercepted by older versions of
>To expand, suppose that we transition to .onion.newtld. This problem,
>among others, would occur: Old versions of Tor that did not know
>about .onion.newtld would try to connect to those addresses by making
>requests to exit nodes through the Tor network. Those exit nodes could
>learn more about who was connecting to .onion addresses.
>We could mitigate this problem, by having a flag day after which all
>supported Tor versions start accepting the new addresses. But then
>we'd need to have a long delay after the new addresses were supported
>by everybody to make everybody stop using the old addresses, before we
>could remove the old anchor.
>> - If such a change where to happen what would be an acceptable timeline
>> for new software to stop supporting the old anchor?
>New software couldn't stop supporting the old anchor until people
>stopped using it.
>People couldn't stop using it until they could know that all existing
>software would support the new anchor.
>People couldn't know that until all current software was unsupported.
>That works out to a few years in practice. (This is somewhat
>dependent on the Debian release cycle in practice; they take security
>patches, but this sure wouldn't be a security patch.)
>So, a full transition would require:
> a few months to spec and implement the transition
> a few years for all previous versions to stop shippin
> a year or two after that for people to update all existing links
>At least, that's what I'd assume. Perhaps there's a faster way I'm not
>> - If the .onion is unsuccessful in its request to be reserver under the
>> mechanism laid out in rfc 6761. Would there be any motivation to
>> change the anchor so that it conformed to a different policy and
>> allow operators and developers to prevent leakage of this name on the
>I imagine there would be some interest, but it would depend on the
>> - Are there any privacy concerns caused by .onion names leaking on to
>> internet in the form of a DNS QNAME by software trying to resolve the
>Yes. In the current hidden service design, it is confidential which
>user wants to visit which address; sending a DNS query with a .onion
>address in it is privacy failure.
>Moreover, in the proposed next-generation hidden service design, the
>address itself is confidential: it is part of a credential that allows
>users who know it to tell that the hidden service exists.
>> - If an organisation where to obtain the .onion name under the gTLD
>> programme are there any privacy concerns considering the organisation
>> could now answer the DNS queries mentioned above. I.e. If a user
>> notatrap.onion without tor configured instead of getting no response the
>> could be redirected to a site controlled by the new owner of the .onion
>There would indeed be such a privacy concern. Moreover, if we stopped
>supporting the old .onion name in Tor, such an organization could
>intercept requests even for Tor users, if users had any stale links or
>addresses using the old TLD.
>Personally, I would consider any such organization to have obviously
>hostile intent, and I would consider any granting of such a gTLD to be
>a transparent message, saying "we don't care about the well-being of
>Tor users at all."
>Anyway, that's my saturday night answer. Perhaps others will think
>more and come up with better answers soon.
>tor-dev mailing list
>tor-dev at lists.torproject.org
More information about the tor-dev