[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
Christian Grothoff:
> Dear all,
>
> Together with Matthias Wachs and Hellekin Wolf, I'm preparing an IESG
> approval request
> for the reservation of special-use domain names for P2P networks
> according to RFC 6761.
> The goal is to reserve .onion, .exit, .i2p, .gnu and .zkey (so that they
> don't become
> ordinary commercial TLDs at some point) and to at the same time document
> their use and
> how they should be processed for the broader community.
>
> I've attached the current draft which we plan to submit shortly (unless,
> of course, we
> receive insightful comments that require major revisions). As two of
> the five pTLDs
> involve Tor, we would be happy for feedback from the Tor developer
> community.
>
>
> Happy hacking!
>
> Christian
Dear Christian,
I've given it an edit pass - I've included the original, a unified diff
and my modified version.
All the best,
Jacob
--- draft.txt 2013-11-09 19:35:23.984361512 +0100
+++ tor-edits-draft.txt 2013-11-09 19:34:14.834361308 +0100
@@ -66,10 +66,11 @@
These pTLDs are used in the GNU Name System (GNS), I2P and the Tor
network to realize fully-decentralized and censorship-resistant
secure alternatives for DNS or, in the case of ".exit", to control
- overlay routing. To facilitate integration with legacy
- applications, the overlay's namespaces can be accessed from
- applications that only speak DNS using these special TLDs, for
- example via specialized SOCKS proxies [RFC 1928].
+ overlay routing and to securely specify path selection choices. To
+ facilitate integration with legacy applications, the overlay's namespaces
+ can be accessed from applications resolve these special TLDs, for example
+ via specialized SOCKS proxies [RFC 1928], through specialized DNS servers or
+ transparent name resolution and ephemeral address mapping.
We will describe the proposed special treatment for each of these
pTLDs below following the questions from [RFC 6761].
@@ -90,10 +91,13 @@
the proposed Special-Use Domain Names already in use on the
Internet and described in this document.
+ The Tor realted names such as 'circuit', 'stream', 'node', 'exit', 'relay'
+ and related Tor terms are described in [Dingledine 2004] and the Tor
+ protocol specification [Tor Protocol Specification].
+
3. Description of Special-Use Domains in P2P Networks
------%<----------------------------------------------------------------
- TODO Add .exit and .noconnect for Tor
TODO Reorganize by app?
------%<----------------------------------------------------------------
@@ -120,49 +124,52 @@
3.3. Circuit-Based Anonymizing pTLDs
- The Tor anonymization network makes use of three special domains to
- date [TorSpec].
+ The Tor anonymization network makes use of several special pTLD
+ domains, three of which have seen widespread usage to date [Tor address-spec.txt].
3.3.1. The Hidden Service ".onion" pTLD
- The widely deployed ".onion" pTLD designates an anonymous hidden
- service reachable via the Tor network [Dingledine 2004]. Such
- addresses are typically resolved via a local SOCKS proxy running on
- TCP port 9050. The purpose of using such a system is to make both
- the information provider and the person accessing the information
- more difficult to trace, whether by one another, by an intermediate
- network host, or by an outsider.
+ The widely deployed ".onion" pTLD designates an anonymous Tor Hidden
+ Service reachable via the Tor network [Dingledine 2004]. These .onion urls
+ are self-authenticating addresses for use with any TCP service. Such
+ addresses are typically resolved, reached and authenticated through transparent
+ proxying or through a local SOCKS proxy running on TCP port 9050, TCP port 9150
+ or another user selected TCP port. The purpose of the Tor Hidden Services
+ system is to provide geographic anonymity for the .onion host and for all
+ clients visiting the hidden service.
Addresses in the ".onion" pTLD are opaque, non-mnemonic, alpha-
- semi-numeric hashes corresponding to the public key of the
- matching Tor hidden service. This "Onion key" is generated
- automatically when the hidden service is configured, following the
- Tor specifications [TorSpec]. It can be made up of any letter of
- the alphabet and decimal digits beginning with 2 and ending with 7,
- thus representing a number in base32 [RFC 4648].
+ semi-numeric hashes corresponding to an 80-bit truncated SHA1 hash over a
+ the Tor hidden service's public key. This "Onion key" is generated
+ automatically when the hidden service is configured and it is used by Tor
+ clients following the Tor Rendezvous specifications [Tor Rendezvous
+ Specification]. It can be made up of any letter of the alphabet and decimal
+ digits beginning with 2 and ending with 7, thus representing a number in base32
+ [RFC 4648].
3.3.2. The Exit Node ".exit" pTLD
- The ".exit" suffix marks a way to access a DNS host via a Tor relay
- nickname, in the form "host.nickname.exit". For example,
- "www.gnu.org.torservers.exit" will route the client to "www.gnu.org"
- via the Tor node named "torservers". In
- "[hostname].[name-or-digest].exit", "hostname" is a valid DNS hostname;
- "[name-or-digest]" is either the nickname of a Tor node or the
- hex-encoded digest of that node's public key. When Tor sees an
- address in this format, it uses the specified hostname as the exit
- node. If no "[hostname]" component is given, Tor defaults to the
- published IPv4 address of the exit node.
+ The ".exit" suffix is used as an in-band source routing control channel,
+ usually it is used for selection of a specific Tor relay during path
+ creation as the last node in the Tor circuit. It may be used to access a DNS
+ host via a Tor relay nickname, in the form "host.nickname.exit". For example,
+ "www.gnu.org.torservers.exit" will route the client to "www.gnu.org" via the
+ Tor node named "torservers". In "[hostname].[name-or-digest].exit", "hostname"
+ is a valid DNS hostname; "[name-or-digest]" is either the nickname of a Tor
+ node or the hex-encoded digest of that node's public key. When Tor sees an
+ address in this format, it uses the specified hostname as the exit node. If no
+ "[hostname]" component is given, Tor defaults to the published IPv4 address of
+ the Tor exit node.
3.3.3. The Interrupting ".noconnect" pTLD
- The ".noconnect" suffix is used in Tor for testing purpose: when
+ The ".noconnect" suffix is used in Tor for testing purposes: when
Tor sees an address in this format, it immediately closes the
connection without attaching it to any circuits. It is useful for
controllers that want to test whether a given application is indeed
- using the same instance of Tor that they're controlling. This is
- a deprecated method and thus do not include ".noconnect" in the
- list of special-use domain names that should be reserved.
+ using the same instance of Tor that they're controlling. This is a
+ deprecated pTLD and thus we do not include ".noconnect" in the list of
+ special-use domain names that should be reserved.
3.4. Packet-Switched-Based Anonymous ".i2p" pTLD
@@ -250,8 +257,8 @@
API. However, for legacy applications and legacy name
resolution APIs, no changes are required.
- The ".onion" pTLDs are typically accessed via SOCKS proxies and
- do not define additional record types.
+ The ".onion" pTLDs are typically accessed via HTTP or SOCKS proxies
+ and do not define additional record types.
The ".i2p" pTLDs are typically accessed via HTTP or SOCKS
proxies and do not define additional record types.
@@ -382,5 +389,18 @@
a Censorship Resistant and Fully Decentralized Name
System", September 2012.
- [TorSpec] Mathewson, N., Dingledine, R., "Special Hostnames in
+ [Tor's address-spec] Mathewson, N., Dingledine, R., "Special Hostnames in
Tor", September 2011.
+ https://gitweb.torproject.org/torspec.git/blob/HEAD:/address-spec.txt
+
+ [Tor's extensions to the SOCKS protocol]
+ https://gitweb.torproject.org/torspec.git/blob/HEAD:/socks-extensions.txt
+
+ [Tor Path Specification] Mathewson, N., Dingledine, R., "Tor Path Specification"
+ https://gitweb.torproject.org/torspec.git/blob/HEAD:/path-spec.txt
+
+ [Tor Rendezvous Specification]
+ https://gitweb.torproject.org/torspec.git/blob/HEAD:/rend-spec.txt
+
+ [Tor Protocol Specification]
+ https://gitweb.torproject.org/torspec.git/blob/HEAD:/tor-spec.txt
Internet Engineering Task Force (IETF) C. Grothoff
IESG Approval document M. Wachs
H. Wolf
TU Munich
Nov 13, 2013
Intended status: IESG Approved
Expires:
Special-Use Domain Names of Peer-to-Peer Name Systems
Abstract
Today, the Domain Name System (DNS) is a key service for the
Internet. DNS is primarily used to map human-memorable names to IP
addresses, which are used for routing but generally not meaningful
for humans. However, the hierarchical nature of DNS makes it
unsuitable for various Peer-to-Peer (P2P) Name Systems. As
compatibility with applications using DNS names is desired, these
overlay networks often define alternative pseudo Top-Level Domains
(pTLDs) to integrate names from the P2P domain into the DNS
hierarchy.
This memo describes five Special-Use Domain Names [RFC 6761] Top
Level Domains (TLDs) designed to help harden name resolution
security (e.g., [RFC 6840][RFC 6975]), provide censorship
resistance, and protect the users' privacy on the Internet.
In this IESG Approval document we are asking for domain name
reservations for those five Special-Use Domain Names [RFC 6761].
The TLDs are ".exit", ".gnu.", ".zkey.", ".onion.", and ".i2p.".
Status of this Memo
This is a WIP draft in preparation for submission to IESG at the
end of this week. This draft is intended for feedback from the
Tor community prior to submission to IESG.
------%<----------------------------------------------------------------
TODO: formatting, review text, review references.
------%<----------------------------------------------------------------
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
1. Introduction
[RFC 6761] defines a mechanism for reserving DNS names for special
use.
This document is an IESG Approval document requesting the
reservation of five pTLDs for special use: ".gnu.", ".i2p.",
".onion.", ".exit" and ".zkey.".
These pTLDs are used in the GNU Name System (GNS), I2P and the Tor
network to realize fully-decentralized and censorship-resistant
secure alternatives for DNS or, in the case of ".exit", to control
overlay routing. To facilitate integration with legacy
applications, the overlay's namespaces can be accessed from
applications that only speak DNS using these special TLDs, for
example via specialized SOCKS proxies [RFC 1928].
We will describe the proposed special treatment for each of these
pTLDs below following the questions from [RFC 6761].
2. Terminology and Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in "Key words for
use in RFCs to Indicate Requirement Levels" [RFC 2119].
The word "peer" is used in the meaning of a individual system on
the network. Thus, "local peer" means the localhost.
The acronym "pTLD" is used as a shortcut to mean a
pseudo-top-level-domain, i.e., a name or label for a network that
is not yet registered with IANA. Specifically, it refers to one of
the proposed Special-Use Domain Names already in use on the
Internet and described in this document.
3. Description of Special-Use Domains in P2P Networks
------%<----------------------------------------------------------------
TODO Add .exit and .noconnect for Tor
TODO Reorganize by app?
------%<----------------------------------------------------------------
3.1. The Human-Memorable ".gnu" pTLD
The ".gnu" pTLD is used to specify that a domain name should be
resolved using GNS instead of DNS. The GNS resolution process is
documented in [Schanzenbach 2012]. As GNS users need to install a
GNS resolver on their individual system and as GNS resolution does
not depend on DNS, there are no considerations for DNS with respect
to the internals of the GNS resolution process itself. Note that
names in the ".gnu" pTLD SHOULD follow the naming conventions of
DNS.
3.2. The Cryptographic-Hash ".zkey" pTLD
The ".zkey" TLD is used to signify that resolution of the given
name MUST be performed using a record signed by an authority that
is in possession of a particular public key. Names in the ".zkey"
domain MUST end with a domain which is the compressed point
representation from EdDSA on Curve25519 of the public key of the
authority, encoded using base32hex [RFC 4648]. A GNS resolver uses
the key to locate a record signed by the respective authority.
3.3. Circuit-Based Anonymizing pTLDs
The Tor anonymization network makes use of three special domains to
date [TorSpec].
3.3.1. The Hidden Service ".onion" pTLD
The widely deployed ".onion" pTLD designates an anonymous hidden
service reachable via the Tor network [Dingledine 2004]. Such
addresses are typically resolved via a local SOCKS proxy running on
TCP port 9050. The purpose of using such a system is to make both
the information provider and the person accessing the information
more difficult to trace, whether by one another, by an intermediate
network host, or by an outsider.
Addresses in the ".onion" pTLD are opaque, non-mnemonic, alpha-
semi-numeric hashes corresponding to the public key of the
matching Tor hidden service. This "Onion key" is generated
automatically when the hidden service is configured, following the
Tor specifications [TorSpec]. It can be made up of any letter of
the alphabet and decimal digits beginning with 2 and ending with 7,
thus representing a number in base32 [RFC 4648].
3.3.2. The Exit Node ".exit" pTLD
The ".exit" suffix marks a way to access a DNS host via a Tor relay
nickname, in the form "host.nickname.exit". For example,
"www.gnu.org.torservers.exit" will route the client to "www.gnu.org"
via the Tor node named "torservers". In
"[hostname].[name-or-digest].exit", "hostname" is a valid DNS hostname;
"[name-or-digest]" is either the nickname of a Tor node or the
hex-encoded digest of that node's public key. When Tor sees an
address in this format, it uses the specified hostname as the exit
node. If no "[hostname]" component is given, Tor defaults to the
published IPv4 address of the exit node.
3.3.3. The Interrupting ".noconnect" pTLD
The ".noconnect" suffix is used in Tor for testing purpose: when
Tor sees an address in this format, it immediately closes the
connection without attaching it to any circuits. It is useful for
controllers that want to test whether a given application is indeed
using the same instance of Tor that they're controlling. This is
a deprecated method and thus do not include ".noconnect" in the
list of special-use domain names that should be reserved.
3.4. Packet-Switched-Based Anonymous ".i2p" pTLD
I2P is an overlay network layer that allows applications to host
websites within the I2P network. These so-called "eepsites" are
addressed using names in the ".i2p" pTLD. They are resolved by the
I2P proxy using either a local lookup table called the
"addressbook", or by decoding Base32-encoded [RFC 4648] public keys
and establishing a tunnel to the respective authority, similar to
contacting hidden services in the ".onion" pTLD. I2P uses 52
characters (256 bits) of the SHA-256 hash of the public key.
4. IANA Considerations
This document is requesting IANA to record the list of domains
below as being Special-Use Domain Names [RFC 6761]:
.gnu.
.i2p.
.onion.
.zkey.
.exit.
4.1. Domain Name Reservation Considerations
The five domains listed above, and any names falling within those
domains (e.g., "example.gnu.", "core.onion.", etc.) are special
[RFC 6761] in the following ways:
------%<----------------------------------------------------------------
Are human users expected to recognize these names as special and
use them differently? In what way?
------%<----------------------------------------------------------------
1. Users MAY use these names as they would other DNS names,
entering them anywhere that they would otherwise enter a
conventional DNS name, or a dotted decimal IPv4 address, or a
literal IPv6 address.
Since there is no central authority responsible for assigning
dot-gnu and dot-i2p names, and that specific domain is local to
the local peer, users SHOULD be aware of that specificity.
Since there is no central authority responsible for assigning
dot-b32-dot-i2p, dot-onion, and dot-zkey names, and those names
match cryptographic keys, users SHOULD be aware that they don't
belong to regular DNS, but are still global in their scope.
In any case, resolution of the five proposed pTLDs is similar to
the normal DNS resolution, and thus SHOULD not affect normal
usage of most Internet applications.
------%<----------------------------------------------------------------
Are writers of application software expected to make their
software recognize these names as special and treat them
differently? In what way? (For example, if a human user enters
such a name, should the application software reject it with an
error message?)
------%<----------------------------------------------------------------
2. Application Software MAY pass requests to any of the five
proposed pTLDs for normal DNS resolution if A/AAAA records are
desired. If available, the local DNS resolver MUST intercept
such requests within the respective operating system hooks and
behave like DNS. However, P2P-aware application MAY choose to
talk directly to the respective P2P resolver, and in the case of
GNS use this to access additional GNS-specific record types.
As mentioned in sections 4.1.4 and 4.1.5 below, regular DNS
resolution is expected to respond with NXDOMAIN for the five
proposed pTLDs. Therefore, if it can differentiate between DNS
and P2P name resolution, application software MAY expect such a
response, and MAY choose to treat other responses from the DNS
as errors.
------%<----------------------------------------------------------------
Are writers of name resolution APIs and libraries expected to
make their software recognize these names as special and treat
them differently? If so, how?
------%<----------------------------------------------------------------
3. Name Resolution APIs and Libraries MAY choose to support
additional GNS record types over time and MAY choose to directly
resolve those domains via a GNS-specific resolution protocol or
API. However, for legacy applications and legacy name
resolution APIs, no changes are required.
The ".onion" pTLDs are typically accessed via SOCKS proxies and
do not define additional record types.
The ".i2p" pTLDs are typically accessed via HTTP or SOCKS
proxies and do not define additional record types.
------%<----------------------------------------------------------------
Are developers of caching domain name servers expected to make
their implementations recognize these names as special and treat
them differently? If so, how?
------%<----------------------------------------------------------------
4. If any request to one of the five considered pTLDs were to
escape to the global operational DNS, the only valid answer from
DNS is NXDOMAIN. Therefore, a caching DNS server MUST respond
with NXDOMAIN. The caching DNS server MAY choose to cache that
response.
------%<----------------------------------------------------------------
Are developers of authoritative domain name servers expected to
make their implementations recognize these names as special and
treat them differently? If so, how?
------%<----------------------------------------------------------------
5. Authoritative DNS Servers are not expected to treat these
TLDs specially. In practice, they SHOULD answer with NXDOMAIN,
as none of the considered pTLDs are normally available via global
DNS resolution, and not doing so MAY put users' privacy at risk,
e.g., as suggested in the next point.
------%<----------------------------------------------------------------
Does this reserved Special-Use Domain Name have any potential
impact on DNS server operators? If they try to configure their
authoritative DNS server as authoritative for this reserved name,
will compliant name server software reject it as invalid? Do DNS
server operators need to know about that and understand why?
Even if the name server software doesn't prevent them from using
this reserved name, are there other ways that it may not work as
expected, of which the DNS server operator should be aware?
------%<----------------------------------------------------------------
6. DNS Server Operators SHOULD treat requests to the five
considered pTLDs as typos, for correct installations MUST not
allow P2P requests to escape to DNS. DNS operators SHOULD NOT
choose to redirect such bogus requests to a site, not even to
explain to the user that their P2P resolver is missing or
mis-configured as this MAY violate privacy expectations of the
user.
------%<----------------------------------------------------------------
How should DNS Registries/Registrars treat requests to register
this reserved domain name? Should such requests be denied?
Should such requests be allowed, but only to a specially-
designated entity? (For example, the name "www.example.org" is
reserved for documentation examples and is not available for
registration; however, the name is in fact registered; and there
is even a web site at that name, which states circularly that the
name is reserved for use in documentation and cannot be
registered!)
------%<----------------------------------------------------------------
7. DNS Registries/Registrars
In order to avoid conflicts with the P2P namespaces, IANA should
reserve all five considered pTLDs and forbid registrars from
registering domains names within their respective scopes.
8. Security Considerations
The five requested Special-Use Domain Names presented in this
document are resolved by specific software outside of the scope of
DNS. Leakage of requests to such domains to the global operational
DNS can cause interception of traffic that might be used to
monitor, censor, or abuse the user's trust, and lead to privacy
issues with potentially dramatic consequences for the user.
Operation of said TLDs into the global DNS scope could as well
produce conflicts due to later real use and the possible
acquisition of intellectual property rights in such names.
The reservation of several top level domain names for these
purposes will minimize such confusion and conflict, and safety
risks for users.
9. Aknowledgements
We thank the I2P developers for their constructive feedback.
------%<----------------------------------------------------------------
TODO
------%<----------------------------------------------------------------
10. References
------%<----------------------------------------------------------------
TODO: validate
------%<----------------------------------------------------------------
10.1. Normative References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997.
[RFC 6761] Cheshire, S. and M. Krochmal, "Special-Use Domain
Names", RFC 6761, February 2013.
10.2. Informative References
[Dingledine 2004] Dingledine, R., Mathewson, N., and Syverson, P.,
"Tor: the second-generation onion router", in SSYM'04
Proceedings of the 13th conference on USENIX Security
Symposium - Volume 13, page 21, 2004.
[RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D.,
and L. Jones, "SOCKS Protocol Version 5", RFC 1928,
March 1996.
[RFC 4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC 6840] Weiler, S., Ed., and D. Blacka, Ed., "Clarifications and
Implementation Notes for DNS Security (DNSSEC)", RFC
6840, February 2013.
[RFC 6975] Crocker, S. and S. Rose, "Signaling Cryptographic
Algorithm Understanding in DNS Security Extensions
(DNSSEC)", RFC 6975, July 2013.
[Schanzenbach 2012] Schanzenbach, M., "Design and Implementation of
a Censorship Resistant and Fully Decentralized Name
System", September 2012.
[TorSpec] Mathewson, N., Dingledine, R., "Special Hostnames in
Tor", September 2011.
Internet Engineering Task Force (IETF) C. Grothoff
IESG Approval document M. Wachs
H. Wolf
TU Munich
Nov 13, 2013
Intended status: IESG Approved
Expires:
Special-Use Domain Names of Peer-to-Peer Name Systems
Abstract
Today, the Domain Name System (DNS) is a key service for the
Internet. DNS is primarily used to map human-memorable names to IP
addresses, which are used for routing but generally not meaningful
for humans. However, the hierarchical nature of DNS makes it
unsuitable for various Peer-to-Peer (P2P) Name Systems. As
compatibility with applications using DNS names is desired, these
overlay networks often define alternative pseudo Top-Level Domains
(pTLDs) to integrate names from the P2P domain into the DNS
hierarchy.
This memo describes five Special-Use Domain Names [RFC 6761] Top
Level Domains (TLDs) designed to help harden name resolution
security (e.g., [RFC 6840][RFC 6975]), provide censorship
resistance, and protect the users' privacy on the Internet.
In this IESG Approval document we are asking for domain name
reservations for those five Special-Use Domain Names [RFC 6761].
The TLDs are ".exit", ".gnu.", ".zkey.", ".onion.", and ".i2p.".
Status of this Memo
This is a WIP draft in preparation for submission to IESG at the
end of this week. This draft is intended for feedback from the
Tor community prior to submission to IESG.
------%<----------------------------------------------------------------
TODO: formatting, review text, review references.
------%<----------------------------------------------------------------
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
1. Introduction
[RFC 6761] defines a mechanism for reserving DNS names for special
use.
This document is an IESG Approval document requesting the
reservation of five pTLDs for special use: ".gnu.", ".i2p.",
".onion.", ".exit" and ".zkey.".
These pTLDs are used in the GNU Name System (GNS), I2P and the Tor
network to realize fully-decentralized and censorship-resistant
secure alternatives for DNS or, in the case of ".exit", to control
overlay routing and to securely specify path selection choices. To
facilitate integration with legacy applications, the overlay's namespaces
can be accessed from applications resolve these special TLDs, for example
via specialized SOCKS proxies [RFC 1928], through specialized DNS servers or
transparent name resolution and ephemeral address mapping.
We will describe the proposed special treatment for each of these
pTLDs below following the questions from [RFC 6761].
2. Terminology and Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in "Key words for
use in RFCs to Indicate Requirement Levels" [RFC 2119].
The word "peer" is used in the meaning of a individual system on
the network. Thus, "local peer" means the localhost.
The acronym "pTLD" is used as a shortcut to mean a
pseudo-top-level-domain, i.e., a name or label for a network that
is not yet registered with IANA. Specifically, it refers to one of
the proposed Special-Use Domain Names already in use on the
Internet and described in this document.
The Tor realted names such as 'circuit', 'stream', 'node', 'exit', 'relay'
and related Tor terms are described in [Dingledine 2004] and the Tor
protocol specification [Tor Protocol Specification].
3. Description of Special-Use Domains in P2P Networks
------%<----------------------------------------------------------------
TODO Reorganize by app?
------%<----------------------------------------------------------------
3.1. The Human-Memorable ".gnu" pTLD
The ".gnu" pTLD is used to specify that a domain name should be
resolved using GNS instead of DNS. The GNS resolution process is
documented in [Schanzenbach 2012]. As GNS users need to install a
GNS resolver on their individual system and as GNS resolution does
not depend on DNS, there are no considerations for DNS with respect
to the internals of the GNS resolution process itself. Note that
names in the ".gnu" pTLD SHOULD follow the naming conventions of
DNS.
3.2. The Cryptographic-Hash ".zkey" pTLD
The ".zkey" TLD is used to signify that resolution of the given
name MUST be performed using a record signed by an authority that
is in possession of a particular public key. Names in the ".zkey"
domain MUST end with a domain which is the compressed point
representation from EdDSA on Curve25519 of the public key of the
authority, encoded using base32hex [RFC 4648]. A GNS resolver uses
the key to locate a record signed by the respective authority.
3.3. Circuit-Based Anonymizing pTLDs
The Tor anonymization network makes use of several special pTLD
domains, three of which have seen widespread usage to date [Tor address-spec.txt].
3.3.1. The Hidden Service ".onion" pTLD
The widely deployed ".onion" pTLD designates an anonymous Tor Hidden
Service reachable via the Tor network [Dingledine 2004]. These .onion urls
are self-authenticating addresses for use with any TCP service. Such
addresses are typically resolved, reached and authenticated through transparent
proxying or through a local SOCKS proxy running on TCP port 9050, TCP port 9150
or another user selected TCP port. The purpose of the Tor Hidden Services
system is to provide geographic anonymity for the .onion host and for all
clients visiting the hidden service.
Addresses in the ".onion" pTLD are opaque, non-mnemonic, alpha-
semi-numeric hashes corresponding to an 80-bit truncated SHA1 hash over a
the Tor hidden service's public key. This "Onion key" is generated
automatically when the hidden service is configured and it is used by Tor
clients following the Tor Rendezvous specifications [Tor Rendezvous
Specification]. It can be made up of any letter of the alphabet and decimal
digits beginning with 2 and ending with 7, thus representing a number in base32
[RFC 4648].
3.3.2. The Exit Node ".exit" pTLD
The ".exit" suffix is used as an in-band source routing control channel,
usually it is used for selection of a specific Tor relay during path
creation as the last node in the Tor circuit. It may be used to access a DNS
host via a Tor relay nickname, in the form "host.nickname.exit". For example,
"www.gnu.org.torservers.exit" will route the client to "www.gnu.org" via the
Tor node named "torservers". In "[hostname].[name-or-digest].exit", "hostname"
is a valid DNS hostname; "[name-or-digest]" is either the nickname of a Tor
node or the hex-encoded digest of that node's public key. When Tor sees an
address in this format, it uses the specified hostname as the exit node. If no
"[hostname]" component is given, Tor defaults to the published IPv4 address of
the Tor exit node.
3.3.3. The Interrupting ".noconnect" pTLD
The ".noconnect" suffix is used in Tor for testing purposes: when
Tor sees an address in this format, it immediately closes the
connection without attaching it to any circuits. It is useful for
controllers that want to test whether a given application is indeed
using the same instance of Tor that they're controlling. This is a
deprecated pTLD and thus we do not include ".noconnect" in the list of
special-use domain names that should be reserved.
3.4. Packet-Switched-Based Anonymous ".i2p" pTLD
I2P is an overlay network layer that allows applications to host
websites within the I2P network. These so-called "eepsites" are
addressed using names in the ".i2p" pTLD. They are resolved by the
I2P proxy using either a local lookup table called the
"addressbook", or by decoding Base32-encoded [RFC 4648] public keys
and establishing a tunnel to the respective authority, similar to
contacting hidden services in the ".onion" pTLD. I2P uses 52
characters (256 bits) of the SHA-256 hash of the public key.
4. IANA Considerations
This document is requesting IANA to record the list of domains
below as being Special-Use Domain Names [RFC 6761]:
.gnu.
.i2p.
.onion.
.zkey.
.exit.
4.1. Domain Name Reservation Considerations
The five domains listed above, and any names falling within those
domains (e.g., "example.gnu.", "core.onion.", etc.) are special
[RFC 6761] in the following ways:
------%<----------------------------------------------------------------
Are human users expected to recognize these names as special and
use them differently? In what way?
------%<----------------------------------------------------------------
1. Users MAY use these names as they would other DNS names,
entering them anywhere that they would otherwise enter a
conventional DNS name, or a dotted decimal IPv4 address, or a
literal IPv6 address.
Since there is no central authority responsible for assigning
dot-gnu and dot-i2p names, and that specific domain is local to
the local peer, users SHOULD be aware of that specificity.
Since there is no central authority responsible for assigning
dot-b32-dot-i2p, dot-onion, and dot-zkey names, and those names
match cryptographic keys, users SHOULD be aware that they don't
belong to regular DNS, but are still global in their scope.
In any case, resolution of the five proposed pTLDs is similar to
the normal DNS resolution, and thus SHOULD not affect normal
usage of most Internet applications.
------%<----------------------------------------------------------------
Are writers of application software expected to make their
software recognize these names as special and treat them
differently? In what way? (For example, if a human user enters
such a name, should the application software reject it with an
error message?)
------%<----------------------------------------------------------------
2. Application Software MAY pass requests to any of the five
proposed pTLDs for normal DNS resolution if A/AAAA records are
desired. If available, the local DNS resolver MUST intercept
such requests within the respective operating system hooks and
behave like DNS. However, P2P-aware application MAY choose to
talk directly to the respective P2P resolver, and in the case of
GNS use this to access additional GNS-specific record types.
As mentioned in sections 4.1.4 and 4.1.5 below, regular DNS
resolution is expected to respond with NXDOMAIN for the five
proposed pTLDs. Therefore, if it can differentiate between DNS
and P2P name resolution, application software MAY expect such a
response, and MAY choose to treat other responses from the DNS
as errors.
------%<----------------------------------------------------------------
Are writers of name resolution APIs and libraries expected to
make their software recognize these names as special and treat
them differently? If so, how?
------%<----------------------------------------------------------------
3. Name Resolution APIs and Libraries MAY choose to support
additional GNS record types over time and MAY choose to directly
resolve those domains via a GNS-specific resolution protocol or
API. However, for legacy applications and legacy name
resolution APIs, no changes are required.
The ".onion" pTLDs are typically accessed via HTTP or SOCKS proxies
and do not define additional record types.
The ".i2p" pTLDs are typically accessed via HTTP or SOCKS
proxies and do not define additional record types.
------%<----------------------------------------------------------------
Are developers of caching domain name servers expected to make
their implementations recognize these names as special and treat
them differently? If so, how?
------%<----------------------------------------------------------------
4. If any request to one of the five considered pTLDs were to
escape to the global operational DNS, the only valid answer from
DNS is NXDOMAIN. Therefore, a caching DNS server MUST respond
with NXDOMAIN. The caching DNS server MAY choose to cache that
response.
------%<----------------------------------------------------------------
Are developers of authoritative domain name servers expected to
make their implementations recognize these names as special and
treat them differently? If so, how?
------%<----------------------------------------------------------------
5. Authoritative DNS Servers are not expected to treat these
TLDs specially. In practice, they SHOULD answer with NXDOMAIN,
as none of the considered pTLDs are normally available via global
DNS resolution, and not doing so MAY put users' privacy at risk,
e.g., as suggested in the next point.
------%<----------------------------------------------------------------
Does this reserved Special-Use Domain Name have any potential
impact on DNS server operators? If they try to configure their
authoritative DNS server as authoritative for this reserved name,
will compliant name server software reject it as invalid? Do DNS
server operators need to know about that and understand why?
Even if the name server software doesn't prevent them from using
this reserved name, are there other ways that it may not work as
expected, of which the DNS server operator should be aware?
------%<----------------------------------------------------------------
6. DNS Server Operators SHOULD treat requests to the five
considered pTLDs as typos, for correct installations MUST not
allow P2P requests to escape to DNS. DNS operators SHOULD NOT
choose to redirect such bogus requests to a site, not even to
explain to the user that their P2P resolver is missing or
mis-configured as this MAY violate privacy expectations of the
user.
------%<----------------------------------------------------------------
How should DNS Registries/Registrars treat requests to register
this reserved domain name? Should such requests be denied?
Should such requests be allowed, but only to a specially-
designated entity? (For example, the name "www.example.org" is
reserved for documentation examples and is not available for
registration; however, the name is in fact registered; and there
is even a web site at that name, which states circularly that the
name is reserved for use in documentation and cannot be
registered!)
------%<----------------------------------------------------------------
7. DNS Registries/Registrars
In order to avoid conflicts with the P2P namespaces, IANA should
reserve all five considered pTLDs and forbid registrars from
registering domains names within their respective scopes.
8. Security Considerations
The five requested Special-Use Domain Names presented in this
document are resolved by specific software outside of the scope of
DNS. Leakage of requests to such domains to the global operational
DNS can cause interception of traffic that might be used to
monitor, censor, or abuse the user's trust, and lead to privacy
issues with potentially dramatic consequences for the user.
Operation of said TLDs into the global DNS scope could as well
produce conflicts due to later real use and the possible
acquisition of intellectual property rights in such names.
The reservation of several top level domain names for these
purposes will minimize such confusion and conflict, and safety
risks for users.
9. Aknowledgements
We thank the I2P developers for their constructive feedback.
------%<----------------------------------------------------------------
TODO
------%<----------------------------------------------------------------
10. References
------%<----------------------------------------------------------------
TODO: validate
------%<----------------------------------------------------------------
10.1. Normative References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997.
[RFC 6761] Cheshire, S. and M. Krochmal, "Special-Use Domain
Names", RFC 6761, February 2013.
10.2. Informative References
[Dingledine 2004] Dingledine, R., Mathewson, N., and Syverson, P.,
"Tor: the second-generation onion router", in SSYM'04
Proceedings of the 13th conference on USENIX Security
Symposium - Volume 13, page 21, 2004.
[RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D.,
and L. Jones, "SOCKS Protocol Version 5", RFC 1928,
March 1996.
[RFC 4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC 6840] Weiler, S., Ed., and D. Blacka, Ed., "Clarifications and
Implementation Notes for DNS Security (DNSSEC)", RFC
6840, February 2013.
[RFC 6975] Crocker, S. and S. Rose, "Signaling Cryptographic
Algorithm Understanding in DNS Security Extensions
(DNSSEC)", RFC 6975, July 2013.
[Schanzenbach 2012] Schanzenbach, M., "Design and Implementation of
a Censorship Resistant and Fully Decentralized Name
System", September 2012.
[Tor's address-spec] Mathewson, N., Dingledine, R., "Special Hostnames in
Tor", September 2011.
https://gitweb.torproject.org/torspec.git/blob/HEAD:/address-spec.txt
[Tor's extensions to the SOCKS protocol]
https://gitweb.torproject.org/torspec.git/blob/HEAD:/socks-extensions.txt
[Tor Path Specification] Mathewson, N., Dingledine, R., "Tor Path Specification"
https://gitweb.torproject.org/torspec.git/blob/HEAD:/path-spec.txt
[Tor Rendezvous Specification]
https://gitweb.torproject.org/torspec.git/blob/HEAD:/rend-spec.txt
[Tor Protocol Specification]
https://gitweb.torproject.org/torspec.git/blob/HEAD:/tor-spec.txt
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev