wdiff draft-adpkja-dnsop-special-names-problem-03.txt draft-adpkja-dnsop-special-names-problem-04.txt

Network Working Group G. Huston
Internet-Draft APNIC
Intended status: Informational P. Koch
Expires: November 25, December 30, 2016 DENIC eG
A. Durand
ICANN
W. Kumari
Google
May 24,
June 28, 2016

Problem Statement for the Reservation of Top-Level Domains in the
Special-Use Domain Names Registry
draft-adpkja-dnsop-special-names-problem-03
draft-adpkja-dnsop-special-names-problem-04

Abstract

The dominant protocol for name resolution on the Internet is the
Domain Name System (DNS). However, other protocols exist that are
fundamentally different from the DNS, and may or may not share the
same namespace.

When an end-user triggers resolution of a name on a system that
supports multiple, different protocols (or or resolution mechanisms), mechanisms, it
is desirable that the protocol used is unambiguous, and that requests
intended for one protocol are not inadvertently answered using
another.
another protocol.

RFC 6761 introduced a framework by which a particular domain name
could be acknowledged as being special. Various challenges have
become apparent with this application of the guidance provided in RFC
6761. This document aims to document those challenges in the form of
a problem statement in order to facilitate further discussion of
potential solutions.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on November 25, December 30, 2016.

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.

Table of Contents

1. Introduction: DNS, Name space or Name Spaces, Name Resolution
Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IETF RFC6761 Special Names . . . . . . . . . . . . . . . . . 3
3. Issues with RFC 6761 . . . . . Itself . . . . . . . . . . . . . . . . . 4
4. Issues with Evaluating Candidate string evaluation String and relationship with Relationship to
the ICANN Process . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 7
A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8
A.2. Change History . . . . . . . . . . . . . . . . . . . . . 7 8
A.2.1. draft-adpkja-special-names-problem-00 . . . . . . . . 7 8
Appendix B. Change history . . . . . . . . . . . . . . . . . . . 7 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8

1. Introduction: DNS, Name space or Name Spaces, Name Resolution
Protocols

For a very long time, DNS "DNS" and the "the name space space" have been perceived
as
one and the same. same thing. However, this has not always been the case; in
the past, other name resolution protocols were popular. One can remember (such as NIS, NIS+, host
files, UUCP addresses... addresses, and others) were popular. Most of those have
been obsoleted by the DNS in the late 1990s. More information on the
history of names and namespaces can be found in
[I-D.lewis-domain-names].

More recently, new name resolution protocols have been proposed, each
addressing a particular need or a particular community. For example,
the DONA handle system [DONA] has been used by parts of the
publication industry. The Apple "Bonjour" set of protocols, inspired
by what was available on Appletalk networks, has been was developed to perform
automatic name resolution on a local IP network. The TOR project is
using the onion system to obfuscate communications, the GNU Name
System (GNS) system is using block chains to build a decentralized
name system to offer "privacy and censorship resistance". Many more
name resolution protocols have been proposed.

Those

These alternate name resolution protocols do not exist in a vacuum.
Application developers have expressed a strong desire to build their
software so it will to function in any of those universes with minimal changes. Doing so means that
In order to do so, the software has to recognize deterministically recognize
what kind of name it is dealing with and associate it with the
corresponding name resolution protocol. Because of this
desired lack of explicit signaling, an An algorithmic solution
frequently chosen by application developers consists simply to use a
special tag padded at the end of a name to indicate an alternate name
resolution method. Examples: For example, if a name ends in .local, the
software uses the Apple Bonjour protocol based on multicast DNS; if
the name ends in .onion, it uses the TOR protocol; if the name ends
in .gnu, it uses the GNS protocol, etc... and so on. One noteworthy
exception to this approach is the DONA system that exists independently and has
developed its own
interoperability solution mechanism with the DNS. Another noteworthy
exception is the Frogans technology [FROGANS] which name space uses
the character '*' to separate network names from site names and allow
any character, including dots on either side of the '*'.

A result of the above is that a number of applications have been
developed (and massively distributed) that have encoded their
favorite "tag" as a DNS TLD in a free-for-all, beginning their
existence by squatting on that DNS space... space; .local, .gnu, .onion
started out like that.

2. IETF RFC6761 Special Names

The IETF used a provision from the IETF/ICANN MoU [RFC2860] section
4.3 that says that "(a) assignments of domain names for technical
uses" is to be considered the purview of IETF (as in, outside (outside of the scope
of ICANN) in order to create a way to reserve such names in a list of
"special names". That process is documented in [RFC6761]
(which curiously (which,
however, does not directly refer the IETF/ICANN MoU). It The [RFC6761]
process was first applied for .local .local, and the more recently for
.onion.

When that the [RFC6761] process was put in place, it was thought it would
only be used a handful of times. However, a large number of
applications have since been made to the IETF. The .onion evaluation
took almost a year and has started a massive (and often heated)
discussion in the IETF.

This [RFC6761] process to reserve special name has a number of
issues, many issues. This
document groups the issues that can be grouped have been brought up in two general
categories:

o Issues with [RFC6761] itself, including issues discovered during
the evaluation of .onion

o Higher level issues Issues regarding evaluating candidate string evaluation strings and the relationship
of this process with ICANN ICANN's processes

3. Issues with RFC 6761 Itself

1. It [RFC6761] can be use used to reserve any names, not just TLDs. For
example, it could potentially be used to forbid a registrar to
register specific names in any TLD.

2. [RFC6761] does not mention if the protocol for which it is
requested to reserve a string using the reserved
name should be published as an RFC document. Most applications
have, so far, come from outside organizations, and the described
protocols that have not been developed by the IETF.

3. [RFC6761] does not provide clear enough direction as to what
party which
group of people is responsible for carrying out the evaluation. evaluation
for inclusion in the registry.

4. There are ambiguities and no formal criteria on how the IETF can
(or even whether the IETF should) evaluate the merits of
applicants to [RFC6761] reservations. Section 5 of [RFC6761]
describes seven questions to be answered by an applicant for
[RFC6761] status. However, running this process for the .onion
application showed that those seven questions are inadequate for
making the determination for whether a particular strings
qualifies as requiring special/different for [RFC6761] treatment.

5. Placing a string in the [RFC6761] registry does not guarantee
that DNS queries for names within a reserved domain will not be
sent over the Internet. As such, the applicant for [RFC6761]
status cannot be guaranteed that leakage will not occur and will
need to take this into account in the their protocol design. Useful
reservations of top-level domains should be accompanied by
documentation of realistic expectations of each of the seven
audiences, and the evaluation of particular requests should
consider the practical likelihood of those expectations being met
and the implications if they are not.

6. The [RFC6761] registry lists the reserved names but does not
include direct guidance, neither in free text form nor in machine
readable instructions, for any of the seven audiences, relying
instead upon audiences. Instead,
the registry relies on a reference for each entry in the Registry to the document
that requested its insertion. Such documents might well could be opaque difficult
to read for many readers; for example, [RFC6762] is a seventy-page 70-page
protocol
specification, for example, specification which is arguably not the most an effective way to set
expectations of non-technical end-users end-users.

4. Issues with Evaluating Candidate string evaluation String and relationship with Relationship to the
ICANN Process

1. The IETF does not have process to evaluate the proposed strings candidate to [RFC6761] status strings for things like
issues such as trademark, IPR, name collision, etc.. and so on. Instead,
the IETF relies on document reviews, working group and IETF-wide
last call, and ultimately a decision is made by the IESG. That
decision can be appealed, first to the IAB and second to the ISOC
board of trusties.

2. The IETF "review" review process is not foolproof. [RFC7788] describing
the "home networking control protocol" was recently published.
That document includes text instructing devices to use names
terminating by default with the .home suffix. [RFC7788] did not
reference [RFC6761] anywhere and had no IANA sections about this
reservation. It was published without anyone noticing this
during the entire review process. The issue was caught after the
publication, and an errata was published.

3. There exists now at least 2 two streams to take strings out of the
global namespace: IETF RFC6761 "special names" the IETF's special-use domain names (described
in [RFC6761]) and ICANN "gTLD
program" (see ICANN's gTLD program (described at [NEW-GTLD]). It is important to observed that the
IETF RFC6761
[RFC6761] reservations could happen in a ad-hoc fashion at any
time, different
times, while ICANN ICANN's gTLD delegations typically happen in batches, and
the latest gTLD round is closed. Note: the
batches. (The ICANN gTLD application process is described in the
applicant guide book
[GUIDEBOOK]. [GUIDEBOOK]). One should note that the
current round of ICANN gTLD is closed to new applications, but
not yet completed as some applications are still under
consideration. One should note that discussions have started
about forming the next round of ICANN gTLDs.

4. The major risk There is having a significant risk of conflict when both the IETF and
ICANN want to use register the same or string, and also when they want
to register similar strings. There exist currently is no defined
mechanism for cooperation between ICANN and IETF to avoid this problem. these
problems.

5. There might could be limited concerns if IETF were to reserve a string
outside of an ICANN gTLD round. The next ICANN gTLD applicant
book would simply refer to the existing list at publication time.
However, there is a possibility of conflict if an IETF reservation were to happen be made
during an a possible future ICANN gTLD round. A hypothetical case study could
for this would be somebody trying prevent a denial of
service attack early in the ICANN application process competitor from
getting a gTLD by asking the IETF to reserved a reserve that string sought after by or a competitor.
similar string.

5. Security Considerations

This document aims to provide a problem statement that will inform
future work. While security and privacy are fundamental
considerations, this document expects that future work will include
such analysis, and hence no attempt is made to do so here. See among
other places
[SAC-057] for further considerations.

Reserving names has been presented as a way to prevent leakage into
the DNS. However, instructing resolvers to not forward the queries
(and/or by instructing authoritative servers not to respond) is not a
guarantee that such leakage will be prevented. The security (or
privacy) of an application MUST NOT rely on names not being exposed
to the Internet DNS resolution system.

6. IANA Considerations

This document has no IANA actions.

7. Acknowledgements

Thanks to Paul Hoffman for a large amount of editing.

8. References

8.1. Normative References

[IANA-SPECIAL-USE]
IANA, "Special-Use Domain Names", 2016,
<https://www.iana.org/assignments/special-use-domain-
names>.

[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860,
DOI 10.17487/RFC2860, June 2000,
<http://www.rfc-editor.org/info/rfc2860>.

[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, DOI 10.17487/RFC6761, February 2013,
<http://www.rfc-editor.org/info/rfc6761>.

[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>.

[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
2016, <http://www.rfc-editor.org/info/rfc7788>.

8.2. Informative References

[DONA] DONA, "DONA Foundation", June 2016,
<https://www.dona.net>.

[FROGANS] Frogans Technology, "Frogans Technology", June 2016,
<https://www.frogans.org>.

[GUIDEBOOK]
ICANN, "gTLD Application Guidebook", June 2012,
<https://newgtlds.icann.org/en/applicants/agb/guidebook-
full-04jun12-en.pdf>.

[HUSTON] Huston, G., "What's in a Name?", December 2015,
<http://www.circleid.com/posts/20151222_whats_in_a_name/>.

[I-D.lewis-domain-names]
Lewis, E., "Domain Names", draft-lewis-domain-names-02
(work in progress), January 2016.

[NEW-GTLD]
ICANN, "New Generic Top-Level Domains", 2016,
<https://newgtlds.icann.org/>.

[SAC-057] ICANN Security and Stability Advisory Committee, "SSAC
Advisory on Internal Name Certificates", March 2013,
<https://www.icann.org/en/system/files/files/sac-
057-en.pdf>.

Appendix A. Editorial Notes

This section (and sub-sections) to be removed prior to publication.

A.1. Venue

An appropriate forum for discussion of this draft is for now the
DNSOP WG.

A.2. Change History

A.2.1. draft-adpkja-special-names-problem-00

Initial draft circulated for comment.

Appendix B. Change history

[ RFC Editor: Please remove this section before publication]

-01 to -02:

o A very large number of readability / grammar / reference fixes
from Paul Hoffman.

-00 to -01:

o Significant readability changes.

-00:

o Initial draft circulated for comment.

Authors' Addresses

Geoff Huston
APNIC

Email: gih@apnic.net

Peter Koch
DENIC eG
Kaiserstrasse 75-77
Frankfurt 60329
Germany

Email: pk@denic.de
Alain Durand
ICANN

Email: alain.durand@icann.org

Warren Kumari
Google

Email: warren@kumari.net