idnits 2.17.1 draft-hardie-arc-pointers-00.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 5 instances 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 -- The document date (October 28, 2016) is 2737 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 296, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hardie 3 Internet-Draft October 28, 2016 4 Intended status: Informational 5 Expires: May 1, 2017 7 Alternative Context Resolution Pointers 8 draft-hardie-arc-pointers-00 10 Abstract 12 In RFC 2826, the IAB set out the benefits of a globally unique public 13 name space. As alternative contexts of resolution emerge, such as 14 those implied by RFC 7686, maintaining a single namespace for the 15 Internet requires a method to indicate the context of resolution for 16 a name. This document proposes a registry for such alternative 17 resolution contexts as well as a set of pointer resource record types 18 useful for allowing conformant resolvers which query for the name in 19 the DNS to be redirected to the appropriate alternative resolution 20 context. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 1, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 1. Introduction 56 RFC 2826[RFC2826] begins "To remain a global network, the Internet 57 requires the existence of a globally unique public name space". At 58 the time it was written, that global name space was expressed almost 59 completely in the DNS, which achieves uniqueness by descent from a 60 single root. 62 As new naming methods have emerged, the distinction between a DNS 63 name and a name in the Internet name space but not in the DNS has 64 been difficult to draw. The Special Use Names registry [RFC6761] has 65 been used to note some alternative name resolution contexts, for 66 example those used by TOR [RFC7686]. This registry is, however, 67 problematic for this use because it permanently links a particular 68 name or label with the resolution method. It is also strongly 69 focused on resolution systems which occupy a place parallel to names 70 in the root zone, creating policy considerations which would not 71 apply to other parts of the Internet name space. 73 This document proposes a set of mechanisms to address the addition of 74 alternative contexts of resolution, with the intent that this be 75 possible at multiple levels of the Internet namespace. 77 2. Basic Approach 79 This document proposes the creation of a registry for alternative 80 resolution contexts which share the Internet's global name space. 81 Entry into this registry will be specification required, with the 82 IESG as the approver of new entries. 84 This document also proposes the creation of a subdomain under .arpa, 85 arc.arpa. Each label under arc.arpa will have an ARC resource record 86 storing a URN from the IETF protocol parameter registry [RFC3553] 87 that identifies the registry entry for the alternative resolution 88 context. Lastly, this document propose the creation of an ARCPOINTER 89 resource recorder. 91 To indicate that part of the Internet namespace uses an alternative 92 resolution context, an ARCPOINTER resource record is placed at the 93 appropriate label. The ARCPOINTER resource record should be the only 94 resource record for that label other than those needed to secure the 95 entry. 97 A system encountering the name first receives the ARCPOINTER resource 98 record, then retrieves the ARC resource record at the domain name to 99 which the ARCPOINTER record referred, if it does not have a cached 100 entry. The URN present at the ARC record is used as a stable 101 identifier with which to index the name resolver's capabilities, so 102 that it asks the right resolution system to provide answers for the 103 name. If it has no match for the URN, the resolution fails. 105 If it does find a match, it resolves the name by presenting the 106 identifier to the alternative resolution system. 108 This allows alternative resolution contexts to be part of the 109 Internet name space at multiple levels of the hierarchy while still 110 matching the syntax expected by URIs and common Internet protocols 111 like HTTP or SMTP. 113 3. Example 115 Imagine that a provider of names based on cryptographic identifiers, 116 the Allium Identifiers Foundation, wishes to reference these names as 117 part of the Internet namespace. The provider furnishes a 118 specification of how these names are dereferenced to IANA, which asks 119 the IESG to review. Upon approval, a new entry is created in the 120 registry and a URN, urn:ietf:params:arc:allium, is assigned. 121 Concurrently, a new label, allium.arc.arpa, is created and populated 122 with an ARC resource record containing the URN. 124 If example.com wishes to use Allium identifiers, it can do so by 125 placing an ARCPOINTER record at the label in their portion of the 126 Internet name space below which the identifiers will appear. An 127 ARCPOINTER record at secid.example.com, for example, means that the 128 Internet name 88917287893.secid.example.com should be interpreted as 129 being the Alium identifier 88917287893, and the Alium resolution 130 context consulted rather than the DNS. 132 An ARC-aware resolver presented with 8917287893.secid.example.com 133 will encounter the ARCPOINTER record pointing to allium.arc.arpa upon 134 attempting to iteratively resolve secid.example.com within the DNS. 135 It will then use the ARC record present at allium.arc.arpa to 136 retrieve the URN urn:ietf:params:arc:allium. The ARC-aware resolver 137 will then match its local capabilties against that index value (Note 138 that the ARC records at a label under arc.arpa should be highly 139 cacheable, so it should not need to retrieve these often). If it has 140 an allium-capable resolution method available, it will present the 141 identifier in the form required by that resolution method. In this 142 case, it might present 88917287893 to the allium subsystem for 143 resolution. In other cases, the fully qualified Internet name will 144 be presented to the identified alternative resolution system. 146 4. A note on Indirection 148 There is a layer of indirection in this approach that may or may not 149 be needed. It is possible to avoid creating the ARCPOINTER resource 150 record and dereferencing labels under arc.arpa entirely, simply by 151 placing ARC records at the same label at which this proposal places 152 ARCPOINTER records. This proposal chose this approach in order to 153 ensure that ARC record entries present in the system were drawn from 154 the registered set. For the Internet name space to remain unique in 155 the presence of alternative resolution systems, both elements of the 156 tuple (name, alternative resolution system identifier) must remain 157 unique. This approach is based on the assumption that having a 158 limited set of places to retrieve the identifiers for alternative 159 resolution systems improves the odds that they will not drift over 160 time. Other methods to achieve this, such as configuring ARC-aware 161 resolvers to reject values not beginning with urn:ietf:params:arc, 162 may be equivalent or needed in any case. 164 5. Applicability 166 There is currently no way to assess the number of systems which are 167 using a portion of the Internet namespace without using DNS 168 resolution, and there is, therefore, an unknown risk of collision as 169 the DNS portion of the namespace grows. Providing a mechanism to 170 permit alternative name resolution to be expressed within the DNS at 171 multiple levels of the hierarchy may mitigate this risk, by allowing 172 the name resolution to start at an arbitrary depth. 174 This approach may also allow for the creation of fairly simple 175 alternative resolution mechanisms. One potential use case is the 176 variant problem. In that use case, a party controls two different 177 identifiers within the Internet namespace and wishes to have them 178 treated as entirely equivalent, so that a resolution request is 179 indifferent to whether or one or the other is used. Within the DNS, 180 this is very difficult to achieve, requiring tight integration at the 181 registries of every level of the namespace involved. It is, however, 182 a very simple alternative resolution. 184 Imagine, for example, that a particular party controls both 185 .colour.example and .color.example and wishes all identifiers using 186 .color.example to be mapped to .colour.example on resolution. By 187 registering an alternative resolution context and placing the 188 appropriate ARCPOINTER and ARC records, that party ensures that any 189 ARC-aware resolver will present names like blue.ismy.favorite.color 190 to an alternative resolution context, which knows to query 191 blue.ismy.favorite.colour and return the answer there. 193 The difficulty with using this for variants is that one answer comes 194 from the DNS and one from an alternative resolution context, so it is 195 not truly a bundled DNS name (even if implemented by consulting the 196 DNS after a transformation). Since the alternative resolution 197 mechanism will have a long road to deployment equivalence with the 198 DNS, this is really only useful when one variant is strongly 199 preferred and the other a permitted alternative. Two equally 200 prefered variants would be hard to assign to a resolution system 201 without implicitly assigning a preference. 203 6. Indicating support for Alternative Resolution 205 Indicating supporting for alternative resolution is one of the most 206 difficult problems in constructing a multi-resolution system for 207 Internet names, as deployment of end-to-end extensions to the DNS is 208 very difficult. As an initial proposal, this document suggests nodes 209 test for support by sending an EDNS[RFC6891] Option Code of (TBD). A 210 resolver capable of alternative resolution should include this Option 211 when sending requests, unless it has cached information which 212 indicates the Internet name is within the DNS. A responder which 213 understands the option must include the Option in its reply. 215 An authoritative server for a zone containing an ARCPOINTER record 216 must not send that record in a response to a request from a system 217 that does not speak EDNS or does not include the relevant option. 218 Instead, it should send an NXDOMAIN response for any name covered by 219 the ARCPOINTER record. This answers the narrow question: "Is this 220 name in the domain name system?" asked by DNS-only resolvers, rather 221 than the broader question "Is this a known Internet name?" which may 222 be asked by systems aware of alternative resolution mechanism. 224 If an alternative-aware requester is speaking to a responder that 225 does not speak EDNS or does not include this option in a reply, it 226 must treat an NXDOMAIN response as a partial answer to the broader 227 question above and should cache such an answer only as a narrow 228 response; it should not assume that there is no such Internet name in 229 any context. It should cache NSEC-validated negative answers, 230 however, as a zone maintainer for a zone containing an ARCPOINTER 231 would not foster aggressive negative caching for the names covered by 232 an ARCPOINTER. 234 The approach laid out above allows for incremental deployment. It 235 has, however, known failure modes that mean a system aware of 236 alternative resolution systems would likely have to manage 237 uncertainty for a long transition. Sending an ARCPOINTER record as 238 additional data to an NXDOMAIN response might be possible, as the 239 semantics of both responses are true, but support for this approach 240 is harder to gauge. 242 The author invites further discussion of this point. 244 7. IANA Considerations 246 This memo, if approved, asks IANA to set up a registry for resolution 247 methods, populate URN parameters for those methods, as well as to 248 register two new DNS resource record types and an EDNS Option. 250 It also asks the IAB to create a new subdomain under .arpa, to be 251 named arc.arpa. Registration of a label under arc.arpa will be 252 permitted on creation of a new entry in the registry noted above, 253 with the only permitted resource records being the ARC record along 254 with the records necessary to secure the entry. 256 7.1. ARC Resource Record 258 =================== 260 TODO: Specify syntax which allows the relevant URNs and, if posible, 261 disallows other options. 263 7.2. ARCPOINTER Resource Record 265 =================== 267 TODO: Specify syntax which permits a pointer to the relevant name 268 under arc.arpa and, if possible, disallows other pointers. 270 7.3. ARC EDNS Option 272 ===================== 274 TODO: Specify syntax. 276 8. Security Considerations 278 This method allows for a different resolution mechanism to replace 279 the standard DNS mechanisms for names in the Internet name space. An 280 attacker capable of redirecting a name into an alternative resolution 281 service will be able to deny name resolution or cause the wrong 282 results to be returned. Because the results must come from a 283 specified alternative resolution service, this does not result in 284 attacker capable of returning completely arbitrary results, but the 285 effect is similar. 287 9. Contributors {Contributors} 289 This document was discussed Warren Kumari, Andrew Sullivan, and 290 Suzanne Wolfe, but all errors are those of the author. 292 10. References 294 10.1. Normative References 296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, 298 DOI 10.17487/RFC2119, March 1997, 299 . 301 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 302 for DNS (EDNS(0))", STD 75, RFC 6891, 303 DOI 10.17487/RFC6891, April 2013, 304 . 306 10.2. Informative References 308 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 309 Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 310 2000, . 312 [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use 313 Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 314 2015, . 316 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 317 RFC 6761, DOI 10.17487/RFC6761, February 2013, 318 . 320 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 321 IETF URN Sub-namespace for Registered Protocol 322 Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 323 2003, . 325 Author's Address 327 Ted Hardie 329 Email: ted.ietf@gmail.com