idnits 2.17.1 draft-klensin-iana-txt-rr-registry-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 26, 2014) is 3656 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J.C. Klensin 3 Internet-Draft A. Sullivan 4 Intended status: Informational Dyn 5 Expires: September 25, 2014 P. Faltstrom 6 Netnod 7 March 26, 2014 9 An IANA Registry for Protocol Uses of Data with the DNS TXT RRTYPE 10 draft-klensin-iana-txt-rr-registry-02 12 Abstract 14 Some protocols use the RDATA field of the DNS TXT RRTYPE for holding 15 data to be parsed, rather than for unstructured free text. This 16 document specifies the creation of an IANA registry for protocol- 17 specific structured data to minimize the risk of conflicting or 18 inconsistent uses of that RRTYPE and data field. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 25, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Registry Contents . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. General Usage Information . . . . . . . . . . . . . . . . 3 56 2.2. Character Sets, Codes, and Restrictions . . . . . . . . . 4 57 3. Adding New Registry Entries . . . . . . . . . . . . . . . . . 4 58 4. Updating Registry Entries . . . . . . . . . . . . . . . . . . 4 59 5. Registration Template . . . . . . . . . . . . . . . . . . . . 5 60 6. Internationalization Considerations . . . . . . . . . . . . . 5 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 66 10.2. Informative References . . . . . . . . . . . . . . . . . 7 67 Appendix A. DNS Parameter and Registry Loose Ends . . . . . . . . 8 68 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . . 9 69 Appendix B.1. Changes from version -00 to -01 . . . . . . . . . 9 70 Appendix B.2. Changes from version -01 to -02 . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 The TXT RRTYPE was defined as part of the initial domain name system 76 (DNS) specification [RFC1035] to hold descriptive text the semantics 77 of which was to be dependent on the domain in which the TXT record 78 was found (paraphrase of part of Section 3.3.14 of RFC 1035). In 79 more recent years, several protocols have used the TXT RRTYPE for 80 structured information to be used by particular protocols, sometimes 81 to avoid creating a separate and specific RRTYPE. There have been 82 extensive discussions about whether that type of use of the TXT 83 RRTYPE is appropriate or desirable; design choices about DNS 84 extensions and some of their consequences are discussed in RFC 5507 85 [RFC5507]. However, independent of how one feels about those issues, 86 the reality is that the DATA fields of TXT RRs are in use for 87 protocol-specific information that is interpreted by the protocols 88 themselves. Those uses are not going to disappear. It is even 89 possible that tradeoffs between established uses, conversion costs, 90 and related issue might justify standardization of the practice, 91 however problematic and/or distasteful that might be in principle. 93 Having structured information that is protocol-specific without a 94 registry increases the risk of different parties using the same 95 identifying information for different purposes, thereby creating 96 security and operational risks. This document specifies the relevant 97 registry. 99 It might be argued that a registry is inappropriate, because it is in 100 effect a subtyping of the TXT RRTYPE. While the position has merit, 101 without a registry and with continued uses of TXT to support pieces 102 of protocol, it is only a matter of time before overlapping or 103 confusable uses turn into an attack. While such an outcome might be 104 accidental, it would still be bad. If there were a registry, then 105 one might dream of zone-checking tools that would warn about 106 apparently-structured information that didn't reflect any of the 107 registered entries. 109 It is important to stress that this registry is intrinsically about 110 what is being done and not about what risks exist and whether 111 particular measures or considerations might mitigate those risks. 113 This document specifies creation of that registry and the means by 114 while it is populated. 116 2. Registry Contents 118 2.1. General Usage Information 120 Each registry entry consists of a reference to the protocol that 121 identifies specific information in the TXT Resource Record's RDATA 122 field and that indicates what information is used to make that 123 identification. For example, if the "foo" protocol were described in 124 RFC 9999 and used the presence of the string "foo=" at the beginning 125 of the first character string in the TXT Resource Record RDATA to 126 identify information that applied to it, the registry would identify 127 the protocol ("foo"), the submitter, the reference that described it 128 ("RFC 9999") and the association-determining string ("foo="). In 129 addition, the registry will identify any constraints on or special 130 properties of the RDATA, such as whether it is restricted to ASCII, 131 expected to be in UTF-8 characters, may contain more than one string, 132 or represents some other type of information. The registry also 133 allows for comment information. That information might include 134 information about prefixes or suffixes for the DNS owner name that 135 are used with the particular protocol at issue. 137 For tracking purposes, each entry also contains date created and date 138 last modified information. 140 2.2. Character Sets, Codes, and Restrictions 142 Section 3.3.14 of the DNS Specification [RFC1035] specifies only that 143 the RRDATA for TXT consists of "One or more s". 144 Section 3.2 specifies that a "is a single length 145 octet followed by that number of characters. is 146 treated as binary information, and can be up to 256 characters in 147 length (including the length octet).". If more that one string is 148 allowed for the particular TXT record, the registration record should 149 indicate that fact and how the multiple strings are interpreted. 150 Similarly, if the character strings are not restricted to ASCII 151 characters, the registration record should discuss how they are to be 152 interpreted, what constraints are applied, and, if the strings are 153 likely to be compared to others, what collation sequences or other 154 rules apply. 156 3. Adding New Registry Entries 158 As discussed when the IETF concluded that there should be fewer 159 barriers to the creation and use of new RRTYPES [RFC6895] best 160 practices today generally call for creating new, protocol- or 161 application-specific types rather than overloading information onto 162 the TXT RRTYPE. Consequently, this registry is expected to reflect 163 deployed existing practices rather than new uses for TXT. Its use to 164 make the latter more acceptable would contradict the intent of both 165 this specification and the registry itself. 167 Consistent with that principle, the procedure for accepting new 168 entries into the registry will be review by a Designated Expert 169 [RFC5226] as modified below. 171 The Expert is expected to determine that the particular use of TXT is 172 in established use and, ideally, is documented with a stable 173 specification as defined by RFC 5226 and the RFC Editor. The 174 existence of a standards track RFC or equivalent specification is 175 always sufficient to meet those conditions. In less common cases, 176 the Expert should consider the explanation above and apply good 177 judgment, favoring adding entries to the registry in cases of doubt. 178 Cases that cannot be resolved adequately by discussion between the 179 applicant and the Expert may be referred to the IESG. 181 4. Updating Registry Entries 182 Registries may be updated using the same mechanisms used to create 183 new ones. The expert reviewer should attempt to ensure that updates 184 are limited to corrections or consistent expansions of earlier 185 information and that the party proposing the update is at least as 186 authoritative about the original protocol as the party who submitted 187 the original registration request. 189 5. Registration Template 191 A registration request should supply the following information, 192 ideally in this form: 194 1. Name and contact information for the submitter. 196 2. Protocol identification and, where feasible, documentation 197 reference. 199 3. Distinguishing characteristics of the TXT RDATA content that 200 permit identifying information for this protocol. 202 4. Character set information and limitations on the RDATA field or 203 an indication that the RDATA are not in character form and 204 whether more than character string is permitted. If more than 205 one character string is permitted, this section of the template 206 should note that and discuss how multiple strings are to be 207 interpreted. This field may be a reference to a stable external 208 document. 210 5. Any special considerations for multiple TXT records with the same 211 owner name. 213 6. If feasible, an explanation of why the TXT RRTYPE is preferred 214 for this particular use over a dedicated, purpose-specific 215 RRTYPE. 217 7. Other special constraint or identifying information. For 218 example, if the protocol being registered requires special 219 prefixes or suffixes for the owner name, a discussion of that 220 requirement. 222 6. Internationalization Considerations 224 As discussed above, the DNS protocol does not restrict TXT RDATA 225 fields to ASCII characters. If appropriate, other character 226 repertoires and encodings, or even octets interpreted as non- 227 character binary information, may be used. For reasons discussed in 228 detail elsewhere, if non-ASCII character data is needed, Unicode 229 encoded in UTF-8 is strongly preferred to other encoding forms or 230 script-specific encodings. Because the use of non-ASCII characters 231 often raises multiple issues, specifically including string 232 comparison choices, registration information should ideally include a 233 discussion of relevant issues (or why there is no issue). 235 For readers needing further information on this subject, different 236 aspects of the string comparison problem for non-ASCII text appear in 237 RFC 2130 [RFC2130], RFC 4790 [RFC4790], RFC 5894 [RFC5894], RFC 6055 238 [RFC6055], and RFC 6885 [RFC6885]. 240 7. IANA Considerations 242 This memo specifies the creation of a new registry in the Domain Name 243 System (DNS) Parameters group [IANA-DNS-Parameters]. The details for 244 the contents and registration requirements for that registry appear 245 in Section 2 and Section 3 above. 247 The registry should have explicit text referencing this document. 248 The text should be similar to the following: 250 "This registry exists to decrease the risk for overlapping use of 251 the TXT Resource Record Type for structured data instead of having 252 the RDATA for that type contain only descriptive text without 253 specified semantics (as described in RFC 1035. See RFC 5507 and 254 the Security Considerations section of RFC NNNN for more 255 information." 257 While it is common practice for registry-creating documents to 258 specify the initial content of the registry, this one deliberately 259 does not do so in order to allow the actual users of the relevant 260 types to identify them and provide explanations for their use. 262 [[Note in draft: The authors disagree as to whether this document 263 should include all known uses of TXT RRTYPE DATA (specifically 264 including all of those discovered in the surveys conducted in 265 conjunction with the SPFbis work) or should create an empty 266 registry and await addition of entries as described in this 267 specification. The advantage of the former is that the registry 268 will contain a useful list of applications of TXT much more 269 quickly. Via the expert review process, the latter would 270 presumably yield better descriptions and information about 271 responsible parties for many entries. A possible middle ground 272 would be to try to identify all uses that are explicitly 273 identified in IETF standards track documents and include them 274 initially, leaving other uses to the registration process.]] 276 8. Security Considerations 278 The creation and use of this registry should help to minimize the 279 risks of different protocols inadvertently using data embedded in TXT 280 Resource Records in incompatible ways. Consequently, it should have 281 a positive effect on security. Because this document and the 282 registry do not address the question of what protocols, if any, 283 should use TXT RDATA in this way, questions associated with the usage 284 and structure of particular protocols lie outside its scope. 286 There is a general (although by no means unanimous) view among DNS 287 experts that overloading RRTYPEs, especially the TXT type, is a bad 288 practice that could lead, not only to the sort of conflicts that this 289 registry might help prevent, but to requirements for multiple queries 290 and even an increased risk from amplification attacks. While caution 291 is always appropriate when documenting a risky practice lest the 292 documentation be taken as endorsement, the arguments for providing 293 documentation for deployed protocol uses of TXT RRs seems very 294 similar to the historical arguments for documenting security risks: 295 being secretive about them won't prevent either their being exploited 296 or prevent new ones from being invented. 298 9. Acknowledgements 300 The requirement for this registry became obvious as a result of the 301 discussion of handing records for SPF in the DNS. The comments of 302 the participants on all sides of that discussion are gratefully 303 acknowledged. 305 Specific comments and text for this draft were provided by Eliot Lear 306 and Subramanian Moonesamy. Dick Francis pointed out the need for a 307 discussion of non-ASCII characters. 309 [[Several useful comments about the general approach taken in the 310 document were received in private notes whose authors may or may not 311 want to be linied to the draft. The originators of such comments 312 should contact the first-listed author if they would like to be 313 listed explicitly.]] 315 10. References 317 10.1. Normative References 319 [IANA-DNS-Parameters] 320 IANA, "Domain Name System (DNS) Parameters", 2013, . 324 [RFC1035] Mockapetris, P., "Domain names - implementation and 325 specification", STD 13, RFC 1035, November 1987. 327 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 328 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 329 May 2008. 331 10.2. Informative References 333 [RFC2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H.T., 334 Atkinson, R., Crispin, M. and P. Svanberg, "The Report of 335 the IAB Character Set Workshop held 29 February - 1 March, 336 1996", RFC 2130, April 1997. 338 [RFC4790] Newman, C., Duerst, M. and A. Gulbrandsen, "Internet 339 Application Protocol Collation Registry", RFC 4790, March 340 2007. 342 [RFC5507] IAB, Faltstrom, P., Austein, R. and P. Koch, "Design 343 Choices When Expanding the DNS", RFC 5507, April 2009. 345 [RFC5894] Klensin, J., "Internationalized Domain Names for 346 Applications (IDNA): Background, Explanation, and 347 Rationale", RFC 5894, August 2010. 349 [RFC6055] Thaler, D., Klensin, J. and S. Cheshire, "IAB Thoughts on 350 Encodings for Internationalized Domain Names", RFC 6055, 351 February 2011. 353 [RFC6885] Blanchet, M. and A. Sullivan, "Stringprep Revision and 354 Problem Statement for the Preparation and Comparison of 355 Internationalized Strings (PRECIS)", RFC 6885, March 2013. 357 [RFC6895] Eastlake, D., "Domain Name System (DNS) IANA 358 Considerations", BCP 42, RFC 6895, April 2013. 360 Appendix A. DNS Parameter and Registry Loose Ends 362 [[RFC Editor: please remove this appendix before publication.]] 364 The discussions surrounding this draft suggest that one or two 365 additional DNS registries may be needed and that the current IANA 366 structure for DNS-related information may not be optimal. In 367 particular, there is no registry for two of the five extension 368 mechanisms described in RFC 5507 as adding prefix or suffixes to 369 owner names. In that context, the registry proposed in this 370 specification can be seen as essentially a subtype registry for the 371 TXT RRTYPE altnough it is deliberately designed to include TXT- 372 related prefixes and suffix approaches as well. It would, however, 373 probably be useful for someone to investigate and, if appropriate, 374 specify additional subtype, prefix, and suffix registries as 375 appropriate. 377 As part of that effort, it may be useful to advise IANA as to whether 378 some or all of the registries at 380 https://www.iana.org/assignments/s-naptr-parameters/s-naptr- 381 parameters.xhtml, 383 https://www.iana.org/assignments/sip-table/sip-table.xhtml, 385 https://www.iana.org/assignments/enum-services/enum- 386 services.xhtml, 388 https://www.iana.org/assignments/im-srv-labels/im-srv- 389 labels.xhtml, 390 https://www.iana.org/assignments/pres-srv-labels/pres-srv- 391 labels.xhtml, 393 https://www.iana.org/assignments/service-names-port-numbers/ 394 service-names-port-numbers.xhtml, 396 and 398 https://www.iana.org/assignments/pkix-parameters/pkix- 399 parameters.xhtml 401 Should be incorporated into, or have crossreference links from, the 402 IANA "Domain Name System (DNS) Parameters" page. 404 Appendix B. Change Log 406 [[RFC Editor: Please remove this appendix before publication.]] 408 Appendix B.1. Changes from version -00 to -01 410 o Added this appendix 412 o Corrected the statement about the absence of an SRV label registry 413 and added that registry to the Appendix Appendix A list. 415 o Small formatting changes to improve readability. 417 o Replaced the discussion among the authors in Section 7 with a 418 summary note. Community input is needed. 420 Appendix B.2. Changes from version -01 to -02 422 o Added provision for identifying character set or similar 423 information and "Internationalization" section. 425 o Added discussion about the contents of RDATA fields. 427 Authors' Addresses 429 John C Klensin 430 1770 Massachusetts Ave, Ste 322 431 Cambridge, MA 02140 432 USA 434 Phone: +1 617 245 1457 435 Email: john-ietf@jck.com 436 Andrew Sullivan 437 Dyn 438 150 Dow St 439 Manchester, NH 03101 440 USA 442 Email: asullivan@dyn.com 444 Patrik Faltstrom 445 Netnod 446 Franzengatan 5 447 112 51 Stockholm, 448 Sweden 450 Email: paf@netnod.se