idnits 2.17.00 (12 Aug 2021)
/tmp/idnits41201/draft-hardie-resolution-contexts-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Couldn't figure out when the document was first submitted -- there may
comments or warnings related to the use of a disclaimer for pre-RFC5378
work that could not be issued because of this. Please check the Legal
Provisions document at https://trustee.ietf.org/license-info to determine
if you need the pre-RFC5378 disclaimer.
-- The document date (March 07, 2016) is 2259 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC7686' is defined on line 258, but no explicit
reference was found in the text
-- Obsolete informational reference (is this intentional?): RFC 7706
(Obsoleted by RFC 8806)
== Outdated reference: A later version (-14) exists of
draft-ietf-dnsop-alt-tld-03
== Outdated reference: A later version (-13) exists of
draft-lewis-domain-names-02
Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Network Working Group T. Hardie
2 Internet-Draft March 07, 2016
3 Intended status: Informational
4 Expires: September 8, 2016
6 Considerations for establishing resolution contexts for Internet Names
7 draft-hardie-resolution-contexts-02
9 Abstract
11 If we model the system of Internet names as a set of directed graphs
12 in an absolute naming context, following RFC 819, an Internet name is
13 not necessarily a name in the domain name system, but is simply a
14 unique name associated with a particular directed graph. The
15 resolution of the name, in other words, is independent from it being
16 an "Internet name". The DNS is a common, but not the only,
17 resolution context for Internet names. This document discusses the
18 consequences of the need to select among multiple resolution
19 contexts.
21 Status of This Memo
23 This Internet-Draft is submitted in full conformance with the
24 provisions of BCP 78 and BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF). Note that other groups may also distribute
28 working documents as Internet-Drafts. The list of current Internet-
29 Drafts is at http://datatracker.ietf.org/drafts/current/.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 This Internet-Draft will expire on September 8, 2015.
38 Copyright Notice
40 Copyright (c) 2015 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (http://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Simplified BSD License text as described in Section 4.e of
50 the Trust Legal Provisions and are provided without warranty as
51 described in the Simplified BSD License.
53 1. Introduction
55 The history in [I-D.lewis-domain-names] and the usage in [RFC3986]
56 both suggest that names registered in the domain name system are part
57 of a larger set of Internet names. If we model the system of
58 Internet names as a set of directed graphs in an absolute naming
59 context, following RFC 819 [RFC0819], an Internet name is not
60 necessarily a name in the domain name system, but is simply a unique
61 name associated with that particular directed graph. The resolution
62 of the name, in other words, is independent from it being an
63 "Internet name". The DNS is a common, but not the only, resolution
64 context for Internet names.
66 2. Resolution Contexts
68 The Domain Name System [RFC1034][RFC1035] provides the most common
69 resolution system for Internet names by many orders of magnitude. It
70 has not, however, met all resolution requirements. Multicast DNS
71 [RFC6762] uses an alternative resolution service, as does TOR [TOR].
72 Tor's .onion names, in particular, appear to be effectively Internet
73 names within a globally shared naming context; they simply happen to
74 use an alternative resolution method.
76 The key practical question that follows from the existence of
77 alternative resolution contexts is how you can determine what
78 resolution context to use for a particular Internet name.
79 Practically, this often means starting with the question of whether
80 it is part of the Domain name set of Internet names, or part of a
81 different set. The de facto signal we are using now is the top-most
82 label of the Internet name. If it is within the known set of DNS
83 top-most labels, we have a definite yes. If it is within an
84 established set of non-DNS top-most labels, we have a definite no.
85 For those with a definite no, there is an available registry set up
86 by [RFC6761] to identify the alternative resolution context or to
87 note that there is no resolution context (as is the case for example
88 domains).
90 There are at least two unfortunate sets of potentially conflicting
91 cases, where people are using labels with the intent to use this
92 signal but have not risen to the level of "established no". In the
93 first case, their usage may be mistaken for non-fully qualified names
94 within the domain name system, resulting in the construction of a new
95 Internet name where one was not intended (e.g. www.sld.allium
96 becoming www.sld.allium.corp.example.com, rather than .allium being
97 used as signal that this Internet name is not within the set of
98 domain names). The second case, which may overlap, is one in which
99 the growth of the set of names in the domain name system causes
100 overlap (a new gTLD like .allium being assigned would conflict with
101 the attempted use of .allium as a resolution context signal).
103 The risks of the two conflicting cases are pretty obvious, but
104 despite that the use of a pseudo-TLD signal seems desirable to many
105 setting up alternative resolution contexts. It seems likely that
106 this is because the services within the alternative resolution
107 contexts wish to use protocols defined for DNS names as if they were
108 defined for their Internet names. The .onion example was driven, in
109 other words, at least in part because its users wanted
110 https://identifier.onion/ to work. In order to share the HTTPS URI
111 context, they needed to minimize the changes to the form of the URI.
112 That meant using https:// with a resolution trigger, rather than
113 changing the URI (tor-https://, for example).
115 The implication for the universe of architecturally appropriate
116 responses is that any means for signalling that a name is not within
117 the DNS context but is still meant to be an Internet name must
118 continue to allow those Internet names to be used in common protocol
119 contexts. It also means that any Internet name must expect
120 restrictions to achieve that (viz. it must be a unique name within a
121 directed graph within the overall Internet name namespace).
123 3. Available Alternatives
125 Given that restriction, the universe of possible resolution context
126 signals seems to be limited. One option is using a designated sub-
127 tree of the Internet namespace for non-DNS resolutions, with labels
128 within the tree indicating which resolution context is meant.
129 [I-D.ietf-dnsop-alt-tld] describes one specific approach to this
130 option. While the use of this sub-tree may be esthetically less
131 pleasing than a pseudo-TLD, it avoids the ambiguities which may arise
132 during the development of alternative resolution context.
134 A second alternative is to fix either the set of top-level domains or
135 the number of resolution contexts, so that ambiguity cannot occur.
136 While a fixed set of top-level domains might have seemed practical
137 when the number of TLDs was limited to country codes and a strictly
138 limited set of generic top-level domains, this has ceased to be a
139 practical alternative. Similarly, the creation of alternative
140 resolution contexts cannot be effectively stifled, even were this
141 desirable; those interested can implement and deploy them without
142 registration of any kind. That these may not interoperate or
143 conflict with other deployments is, of course, a risk.
145 A third alternative within the DNS context is to continue the current
146 registration of pseudo-TLDs and accept the consequences of ambiguity.
147 This will mean that conflicts between pseudo-TLDs marking alternative
148 resolution contexts and potential future TLDs must be managed and
149 that the operational impact must be addressed. A focus on deployment
150 of mitigation strategies may reduce the operational consequences. As
151 an example, the deployment of loopback root zones [RFC7706] will
152 reduce the impact of queries for pseudo-TLDs leaking to the root DNS
153 name servers. Similarly, policies for names registered as pseudo-
154 TLDs may also limit potential conflict.
156 An alternative to signals within the DNS is making alternative
157 signals easier. URI registrations have gotten significantly
158 easier[RFC7595] over time, but it might be possible to lower the bar
159 further by creating a convention for using alternative resolution
160 contexts.
162 As an example, we could set aside a string delimiter for this purpose
163 as we set aside xn- to single out the ACE encoding for
164 Internationalized Domain Names [RFC5891]. That string delimiter
165 could then be used to construct faceted URI schemes, one aspect of
166 which contained the usual protocol indicator and the other the
167 resolution context. The ABNF for scheme is:
169 scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
171 Setting aside a string delimiter such as +.+ would allow something
172 like https://identifier.onion/ to become https+.+tor//identifier/.
173 This would require updates to URI parsing libraries that intended to
174 handle alternative resolution contexts, but the use of a common
175 delimiter would lower the amount of code needed both to identify the
176 core protocol and the alternative resolution contexts. It might
177 remain esthetically less pleasing, however, and it would prevent the
178 use of IDNA-permitted characters as resolution context identifiers,
179 something which the DNS-based solutions do allow.
181 4. Conclusions
183 There are clearly trade-offs among the available alternatives, as
184 each has its own drawbacks as an indicator of resolution context.
185 Given, however, that the existence of multiple signals could generate
186 even further interoperability issues and operational concerns, the
187 creation of multiple signals is undesirable. Any system which allows
188 Internet names from alternate resolution contexts to be used in
189 common protocol systems can likely be made to work, provided its
190 drawbacks are accounted for and mitigated appropriately.
192 5. Security Considerations
194 This document describes a number of potential method for establishing
195 a resolution context for an Internet name. Should the resolution
196 context to be used with a name not be sufficiently clear, it may be
197 possible to provide alternative information in a different context.
198 That alternative information could provide an avenue for an attacker
199 to stand up services which would mimic those present elsewhere,
200 allowing the attacker to subvert the connection, steal credentials,
202 6. IANA Considerations
204 This document currently has no actions for IANA.
206 7. Acknowledgements
208 Thanks to Ed Lewis, Suzanne Wolff, and Andrew Sullivan for
209 conversations leading up to this document; all errors of fact and
210 judgement are, however, the author's.
212 8. Informative References
214 [TOR] The Tor Project, "Tor", 2013,
215 .
217 [RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for
218 Internet User Applications", RFC 819,
219 DOI 10.17487/RFC0819, August 1982,
220 .
222 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
223 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
224 .
226 [RFC1035] Mockapetris, P., "Domain names - implementation and
227 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
228 November 1987, .
230 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
231 Resource Identifier (URI): Generic Syntax", STD 66,
232 RFC 3986, DOI 10.17487/RFC3986, January 2005,
233 .
235 [RFC5891] Klensin, J., "Internationalized Domain Names in
236 Applications (IDNA): Protocol", RFC 5891,
237 DOI 10.17487/RFC5891, August 2010,
238 .
240 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
241 RFC 6761, DOI 10.17487/RFC6761, February 2013,
242 .
244 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
245 DOI 10.17487/RFC6762, February 2013,
246 .
248 [RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root
249 Servers by Running One on Loopback", RFC 7706,
250 DOI 10.17487/RFC7706, November 2015,
251 .
253 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
254 and Registration Procedures for URI Schemes", BCP 35,
255 RFC 7595, DOI 10.17487/RFC7595, June 2015,
256 .
258 [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use
259 Domain Name", RFC 7686, DOI 10.17487/RFC7686, October
260 2015, .
262 [I-D.ietf-dnsop-alt-tld]
263 Kumari, W. and A. Sullivan, "The ALT Special Use Top Level
264 Domain", draft-ietf-dnsop-alt-tld-03 (work in progress),
265 September 2015.
267 [I-D.lewis-domain-names]
268 Lewis, E., "Domain Names", draft-lewis-domain-names-02
269 (work in progress), January 2016.
271 Author's Address
273 Ted Hardie
275 Email: ted.ietf@gmail.com