Re: [tor-dev] Registering special-use domain names of peer-to-peer name systems with IETF
Hello All, Im writing to the list in response to IETF submission made by christian. 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)? - If such a change where to happen what would be an acceptable timeline for new software to stop supporting the old anchor? - 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 - 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 - 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. Thanks John [1]http://www.ietf.org/mail-archive/web/dnsop/current/msg10785.html [2]http://www.ietf.org/mail-archive/web/dnsop/current/msg11074.html [3]http://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-names-01 [4]http://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-00 [5]http://tools.ietf.org/html/rfc6761
On Thu, Feb 13, 2014 at 9:06 AM, John Bond <mail@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[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
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@alum.mit.edu> Reply-To: <tor-dev@lists.torproject.org> Date: Sunday 16 February 2014 03:51 To: <tor-dev@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@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[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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
participants (2)
-
John Bond -
Nick Mathewson