[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] Registering special-use domain names of peer-to-peer name systems with IETF



Hello Nick,

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.

Thanks John

-----Original Message-----
From: Nick Mathewson <nickm@xxxxxxxxxxxx>
Reply-To: <tor-dev@xxxxxxxxxxxxxxxxxxxx>
Date: Sunday 16 February 2014 03:51
To: <tor-dev@xxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxx> 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[1] and has also
>> seen another draft to be proposed[2].  I will start by saying I see
>>merit
>> in both drafts being proposed[3][4] 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
>>may
>> be)?
>
>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
>Tor.
>
>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
>everywhere.
>
>At least, that's what I'd assume.  Perhaps there's a faster way I'm not
>seeing.
>
>>  - If the .onion is unsuccessful in its request to be reserver under the
>> mechanism laid out in rfc 6761[5].  Would there be any motivation to
>> change the anchor so that it conformed to a different policy and
>>therefore
>> allow operators and developers to prevent leakage of this name on the
>> internet
>
>I imagine there would be some interest, but it would depend on the
>benefits.
>
>>  - Are there any privacy concerns caused by .onion names leaking on to
>>the
>> internet in the form of a DNS QNAME by software trying to resolve the
>>name
>
>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
>>requested
>> 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
>> domain.
>
>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.
>
>best wishes,
>-- 
>Nick
>_______________________________________________
>tor-dev mailing list
>tor-dev@xxxxxxxxxxxxxxxxxxxx
>https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>


_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev