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