Dear all, Following https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/ and the separation of .onion in https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-01 to satisfy the IETF's desire to have lots of documents, I've now split off ".exit" as well to create draft-grothoff-iesg-special-use-p2p-exit-00 I've attached the current draft to this e-mail and would appreciate any feedback you may have. Also, if you feel that this is the wrong move entirely (i.e. because you don't want to reserve .exit), please do let me know ASAP and then I won't submit the draft. Happy hacking! Christian
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml";>
<!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml";>
<!ENTITY RFC1928 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1928.xml";>
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml";>
<!ENTITY RFC2308 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2308.xml";>
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml";>
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml";>
<!ENTITY RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml";>
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml";>
<!ENTITY RFC6761 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6761.xml";>
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml";>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info"
docName="draft-grothoff-iesg-special-use-p2p-exit-00"
ipr="trust200902">
<front>
<title abbrev="Special-Use-p2p-Exit">
The .exit Special-Use Domain Name of Tor
</title>
<author fullname="Christian Grothoff" initials="C.G." surname="Grothoff">
<organization>INRIA</organization>
<address>
<postal>
<street>Équipe Décentralisée</street>
<street>INRIA Rennes Bretagne Atlantique</street>
<street>263 avenue du Général Leclerc</street>
<street>Campus Universitaire de Beaulieu</street>
<city>Rennes</city>
<region>Bretagne</region>
<code>F-35042</code>
<country>FR</country>
</postal>
<email>christian@xxxxxxxxxxxx</email>
</address>
</author>
<author fullname="Matthias Wachs" initials="M.W." surname="Wachs">
<organization>Technische Universität München</organization>
<address>
<postal>
<street>Free Secure Network Systems Group</street>
<street>Lehrstuhl fuer Netzarchitekturen und Netzdienste</street>
<street>Boltzmannstrasse 3</street>
<street>Technische Universitaet Muenchen</street>
<code>D-85748</code>
<city>Garching bei Muenchen</city>
<region>Bayern</region>
<country>DE</country>
</postal>
<email>wachs@xxxxxxxxxxxxx</email>
</address>
</author>
<author fullname="Hellekin O. Wolf" initials="H.O.W." role="editor"
surname="Wolf">
<organization>GNU consensus</organization>
<address>
<email>hellekin@xxxxxxx</email>
</address>
</author>
<author fullname="Jacob Appelbaum" initials="J.A." surname="Appelbaum">
<organization>Tor Project Inc.</organization>
<address>
<email>jacob@xxxxxxxxxxxxx</email>
</address>
</author>
<author fullname="Leif Ryge" initials="L.R." surname="Ryge">
<organization>Tor Project Inc.</organization>
<address>
<email>leif@xxxxxxxxxxxxx</email>
</address>
</author>
<date day="24" month="January" year="2015" />
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>special-use</keyword>
<keyword>peer-to-peer</keyword>
<keyword>domain names</keyword>
<keyword>Tor</keyword>
<abstract>
<t>This document registers a set of Special-Use Domain Names for
use with the Tor Project, as per RFC6761.</t>
</abstract>
</front>
<middle>
<section anchor="introduction"
title="Introduction">
<t>The Domain Name System (DNS) is primarily used to map
human-memorable names to IP addresses, which are used for
routing but generally not meaningful for humans.</t>
<t>The Tor project supports the use of names to specify
where the user wishes to exit the P2P overlay.</t>
<t>As compatibility with applications using domain names is
desired, this mechanism requires an exclusive
alternative Top-Level Domains to avoid conflict between the Tor
namespace and the DNS hierarchy.</t>
<t>In order to avoid interoperability issues with DNS as well as
to address security and privacy concerns, this document
registers the "EXIT" Special-Use Domain Names for use within
the Tor network, as per <xref target="RFC6761"/>.</t>
<t>The Tor network uses this pTLD
to control overlay routing and to securely specify path
selection choices <xref target="TOR-PATH"/>.</t>
</section>
<section anchor="applicability"
title="Applicability">
<t><xref target="RFC6761"/> Section 3 states:</t>
<t><list style="empty"><t>"[I]f a domain name has special
properties that affect the way hardware and software
implementations handle the name, that apply universally
regardless of what network the implementation may be connected
to, then that domain name may be a candidate for having the IETF
declare it to be a Special-Use Domain Name and specify what
special treatment implementations should give to that name. On
the other hand, if declaring a given name to be special would
result in no change to any implementations, then that suggests
that the name may not be special in any material way, and it may
be more appropriate to use the existing DNS mechanisms <xref
target="RFC1034"/> to provide the desired delegation, data, or
lack-of-data, for the name in question. Where the desired
behaviour can be achieved via the existing domain name
registration processes, that process should be used. Reservation
of a Special-Use Domain Name is not a mechanism for
circumventing normal domain name registration
processes."</t></list></t>
<t>The set "EXIT" pTLD
reserved by this document meets this requirement, as it
has the following specificities:</t>
<t><list style="symbols">
<t>"EXIT" resolution does not depend on the DNS context:
The name specifies a Tor exit node, and thus the response is not
even really DNS-compatible; Tor uses its own
P2P protocols for resolving the destination specified in an .exit
name.</t>
<t>When Tor is properly implemented, the
implementation MUST intercept queries for the "EXIT" to ensure
that these Tor-specific names cannot leak into the DNS.</t>
<t>Finally, in order for Tor to properly interoperate with DNS
and to provide security and privacy features matching user
expectations, this document specifies desirable changes in
existing DNS software and DNS operations.</t>
</list></t>
</section>
<section anchor="terminology-and-conventions"
title="Terminology and Conventions Used in This Document">
<t>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 <xref target="RFC2119"/>.</t>
<t>The word "peer" is used in the meaning of a
individual system on the network.</t>
<t>The abbreviation "pTLD" is used in this document to
mean a pseudo Top-Level Domain, i.e., a Special-Use Domain Name
per <xref target="RFC6761"/> reserved to P2P Systems in this
document. A pTLD is mentioned in capitals, and within double
quotes to mark the difference with a regular DNS gTLD.</t>
<t>In this document, ".tld" (lowercase, with quotes)
means: any domain or hostname within the scope of a given pTLD,
while .tld (lowercase, without quotes) refers to an adjective
form. </t>
<t>The word "NXDOMAIN" refers to an alternate
expression for the "Name Error" RCODE as described in
section 4.1.1 of <xref target="RFC1035"/>. When referring to
"NXDOMAIN" and negative caching <xref
target="RFC2308"/> response, this document means an
authoritative (AA=1) name error (RCODE=3) response
exclusively.</t>
<t>The Tor-related names such as 'circuit', 'exit', 'node',
'relay', 'stream', and related Tor terms are described in <xref
target="Dingledine2004"/> and the Tor protocol specification
<xref target="TOR-PROTOCOL"/>.</t>
</section>
<section anchor="dot-exit"
title="The "EXIT" Client Source Routing pTLD">
<t>The .exit suffix is used as an in-band source routing
control channel, usually for selection of a specific Tor
relay during path creation as the last node in the Tor
circuit.</t>
<t>It may be used to access a DNS host via specific
Torservers, in the form
"hostname.nickname-or-fingerprint.exit", where the
"hostname" is a valid hostname, and the
"nickname-or-fingerprint" is either the nickname
of a Tor relay in the Tor network consensus, or the
hex-encoded SHA1 digest of the given node's public key
(fingerprint).</t>
<t>For example, "gnu.org.noisetor.exit" will route
the client to "gnu.org" via the Tor node nicknamed
"noisetor". Using the fingerprint instead of the
nickname ensures that the path selection uses a specific Tor
exit node, and is harder to remember: e.g.,
"gnu.org.f97f3b153fed6604230cd497a3d1e9815b007637.exit".</t>
<t>When Tor sees an address in this format, it uses the
specified "nickname-or-fingerprint" as the exit
node. If no "hostname" component is given, Tor
defaults to the published IPv4 address of the Tor exit node
<xref target="TOR-EXTSOCKS"/>.</t>
<t>Because "hostname" is allegedly valid, the
total length of a .exit construct may exceed the maximum
length allowed for domain names. Moreover, the resolution
of "hostname" happens at the exit node. Trying to
resolve such invalid domain names, including chaining .exit
names will likely return a DNS lookup failure at the first
exit node.</t>
<t>The "EXIT" domain is special in the following
ways:</t>
<t><list style="numbers">
<!-- 1. Users Considerations -->
<t>Users can use these names as they would other domain
names, entering them anywhere that they would otherwise
enter a conventional DNS domain name.
<vspace blankLines="1"/>
Since .exit names correspond to a Tor-specific routing
construct to reach target hosts via chosen Tor exit nodes,
users need to be aware that they do not belong to regular
DNS and that the actual target precedes the second-level
domain name.
<vspace blankLines="1"/>
</t>
<!-- 2. Application Software Considerations -->
<t>Application software MAY recognize that .exit domains
are special and when they do SHOULD NOT pass requests for
these domains to DNS resolvers and libraries.
<vspace blankLines="1"/>
As mentioned in items 4 and 5 below, regular DNS
resolution is expected to respond with NXDOMAIN.
Therefore, if it can differentiate between DNS and P2P
name resolution, application software:
<list style="symbols">
<t>MUST expect NXDOMAIN as the only valid DNS response,
and</t>
<t>SHOULD treat other answers from DNS as errors.</t>
</list>
<vspace blankLines="1"/>
Tor-aware applications MAY also use Tor resolvers directly.
</t>
<!-- 3. Name Resolution APIs and Libraries Considerations -->
<t>Name resolution APIs and libraries SHOULD either
respond to requests for .exit names by resolving them via
the Tor protocol, or respond with NXDOMAIN.
<vspace blankLines="1"/>
</t>
<!-- 4. Caching DNS Servers Considerations -->
<!-- TODO: specify negative responses -->
<t>Caching DNS servers SHOULD recognize .exit names as
special and SHOULD NOT, by default, attempt to look up NS
records for them, or otherwise query authoritative DNS
servers in an attempt to resolve .exit names. Instead,
caching DNS servers SHOULD, by default, generate immediate
negative responses for all such queries.
<vspace blankLines="1"/>
</t>
<!-- 5. Authoritative DNS Servers Considerations -->
<t>Authoritative DNS servers are not expected to treat
.exit domain requests specially. In practice, they MUST
answer with NXDOMAIN, as "EXIT" is not available
via global DNS resolution, and not doing so MAY put users'
privacy at risk (see item 6).
<vspace blankLines="1"/>
</t>
<!-- 6. DNS Server Operators Considerations -->
<t>DNS server operators SHOULD be aware that .exit names
are reserved for use with Tor, and MUST NOT override their
resolution (e.g., to redirect users to another service or
error information).
<vspace blankLines="1"/>
</t>
<!-- 7. DNS Registries/Registrars Considerations -->
<t>DNS registries/registrars MUST NOT grant any request to
register .exit names. This helps avoid conflicts <xref
target="SAC45"/>. These names are defined by the Tor
address specification, and they fall outside the set of
names available for allocation by registries/registrars.
<vspace blankLines="1"/>
</t>
</list></t>
</section>
</section>
<section anchor="security-considerations"
title="Security Considerations">
<t>Specific software performs the resolution of the six
Special-Use Domain Names presented in this document; this
resolution process happens 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 misused to monitor,
censor, or abuse the user's trust, and lead to privacy issues
with potentially tragic consequences for the user.</t>
<t>This document reserves these Top-Level Domain names to
minimize the possibility of confusion, conflict, and especially
privacy risks for users.</t>
<t>In the introduction of this document, there's a requirement
that DNS operators do not override resolution of the "EXIT"
Names.
This is a regulatory measure and cannot prevent such malicious
abuse in practice. Its purpose is to limit any information leak
that would result from incorrectly configured systems, and to
avoid that resolvers make unnecessary contact to the DNS Root
Zone for such domains. Verisign, Inc., as well as several
Internet service providers (ISPs) have notoriously abused their
position to override NXDOMAIN responses to their customers in
the past <xref target="SSAC-NXDOMAIN-Abuse"/>. For example, if
a DNS operator would decide to override NXDOMAIN and send
advertising to leaked .onion sites, the information leak to the
DNS would extend to the advertising server, with unpredictable
consequences. Thus, implementors should be aware that any
positive response coming from DNS must be considered with extra
care, as it suggests a leak to DNS has been made, contrary to
user's privacy expectations.</t>
<t>The reality of X.509 Certificate Authorities (CAs) creating
misleading certificates for these pTLDs due to ignorance
stresses the need to document their special use.
Certificate Authorities MUST NOT create
certificates for "EXIT" Top-level domains.
Nevertheless, clients SHOULD
accept certificates for these Top-Level domains as they may be
created legitimately by local proxies on the fly.
</t>
<t>Finally, legacy applications that do not explicitly support
the pTLD significantly increase the risk of pTLD queries
escaping to DNS, as they are entirely dependent on the correct
configuration on the operating system.</t>
</section>
<section anchor="iana-considerations"
title="IANA Considerations">
<t>The Internet Assigned Numbers Authority (IANA) reserved the
following entries in the Special-Use Domain Names registry <xref
target="RFC6761"/>:</t>
<t><list>
<t> .exit</t>
</list></t>
<t>[TO REMOVE: the assignement URL is
https://www.iana.org/assignments/special-use-domain-names/ ]</t>
</section>
<section anchor="acknowledgements"
title="Acknowledgements">
<t>The authors thank the I2P and Namecoin developers for their
constructive feedback, as well as Mark Nottingham for his
proof-reading and valuable feedback. The authors also thank the
members of DNSOP WG for their critiques and suggestions.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC1034;
&RFC1035;
&RFC2119;
&RFC2308;
&RFC5226;
&RFC6761;
</references>
<references title="Informative References">
<reference anchor="Dingledine2004"
target="https://www.onion-router.net/Publications/tor-design.pdf";>
<front>
<title>Tor: the second-generation onion router</title>
<author initials="R.D." fullname="Roger Dingledine" surname="Dingledine">
<organization>The Free Haven Project</organization>
</author>
<author initials="N.M." fullname="Nick Mathewson" surname="Mathewson">
<organization>The Free Haven Project</organization>
</author>
<author initials="P.S." fullname="Paul Syverson" surname="Syverson">
<organization>Naval Research Lab</organization>
</author>
<date year="2004" />
</front>
</reference>
<reference anchor="SSAC-NXDOMAIN-Abuse"
target="http://www.icann.org/committees/security/ssac-report-09jul04.pdf";>
<front>
<title>Redirection in the COM and NET Domains</title>
<author>
<organization>ICANN Security and Stability Advisory
Committee</organization>
</author>
<date month="July" year="2004"/>
</front>
</reference>
&RFC4648;
<reference anchor="SAC45"
target="http://www.icann.org/en/groups/ssac/documents/sac-045-en.pdf";>
<front>
<title>Invalid Top Level Domain Queries at the Root
Level of the Domain Name System</title>
<author>
<organization>ICANN Security and Stability Advisory
Committee</organization>
</author>
<date month="November" year="2010"/>
</front>
</reference>
<reference anchor="TOR-ADDRESS"
target="https://gitweb.torproject.org/torspec.git/plain/address-spec.txt";>
<front>
<title>Special Hostnames in Tor</title>
<author initials="N.M." fullname="Nick Mathewson" surname="Mathewson">
<organization>Tor Project Inc.</organization>
</author>
<author initials="R.D." fullname="Roger Dingledine" surname="Dingledine">
<organization>Tor Project Inc.</organization>
</author>
<date year="2011" month="September" />
</front>
</reference>
<reference anchor="TOR-EXTSOCKS"
target="https://gitweb.torproject.org/torspec.git/plain/socks-extensions.txt";>
<front>
<title>Tor's extensions to the SOCKS protocol</title>
<author initials="N.M." fullname="Nick Mathewson" surname="Mathewson">
<organization>Tor Project Inc.</organization>
</author>
<author initials="R.D." fullname="Roger Dingledine" surname="Dingledine">
<organization>Tor Project Inc.</organization>
</author>
<date year="2014" month="February" />
</front>
</reference>
<reference anchor="TOR-PATH"
target="https://gitweb.torproject.org/torspec.git/plain/path-spec.txt";>
<front>
<title>Tor Path Specification</title>
<author initials="N.M." fullname="Nick Mathewson" surname="Mathewson">
<organization>Tor Project Inc.</organization>
</author>
<author initials="R.D." fullname="Roger Dingledine" surname="Dingledine">
<organization>Tor Project Inc.</organization>
</author>
<date year="2014" month="November" />
</front>
</reference>
<reference anchor="TOR-PROTOCOL"
target="https://gitweb.torproject.org/torspec.git/plain/tor-spec.txt";>
<front>
<title>Tor Protocol Specification</title>
<author initials="R.D." fullname="Roger Dingledine" surname="Dingledine">
<organization>Tor Project Inc.</organization>
</author>
<author initials="N.M." fullname="Nick Mathewson" surname="Mathewson">
<organization>Tor Project Inc.</organization>
</author>
<date year="2014" month="August" />
</front>
</reference>
<reference anchor="TOR-RENDEZVOUS"
target="https://gitweb.torproject.org/torspec.git/plain/rend-spec.txt";>
<front>
<title>Tor Rendezvous Specification</title>
<author initials="N.M." fullname="Nick Mathewson" surname="Mathewson">
<organization>Tor Project Inc.</organization>
</author>
<author initials="R.D." fullname="Roger Dingledine" surname="Dingledine">
<organization>Tor Project Inc.</organization>
</author>
<date year="2014" month="April" />
</front>
</reference>
<!-- Change Log
v00 2013-11-13 HOW Initial version
v01 2013-12-05 HOW First XML version
- Fix conformance issues
- Shorten abstract
- Remove appendix on Tor reference
- Add .bit
- Reorder references
- Integrate community feedback
v02 2014-02-15 HOW Second XML version
- Split Reservation Considerations for each pTLD
- Revise abstract
- Explain .exit exceeded length unpredictability
- Integrate community feedback
v03 2014-12-21 HOW Third XML version
- Shorten abstract and focus scope
- Expand security considerations:
- Add reference to SSL certificates for non-DNS domains
- Add reference to SSAC recommendations on name collisions
- Update GNUnet references
- Update I2P reference
- Update Namecoin reference
- Update Tor references
- Remove alternate use of dot-tld notation
- Added Leif as author
- Integrate community feedback
v04 2015-01-24 HOW Fourth XML version
- Move I2P under geographic anonymity section
- Integrate I2P developers comments
- Integrate Namecoin developers comments
- Add security considerations
- Integrate community feedback
v05 2015-06-22 CG First split version
- split into separate drafts for each name system
- Removed .onion as that's already a separate draft
-->
</back>
</rfc>
Attachment:
0xE29FC3CC.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev