Network Working Group J.C. Klensin Internet-Draft A. Sullivan Intended status: Informational Dyn Expires: September 02, 2014 P. A. Faltstrom Netnod March 3, 2014 An IANA Registry for Protocol Uses of Data with the DNS TXT RRTYPE draft-klensin-iana-txt-rr-registry-01 Abstract Some protocols use the RDATA field of the DNS TXT RRTYPE for holding data to be parsed, rather than for unstructured free text. This document specifies the creation of an IANA registry for protocol- specific structured data to minimize the risk of conflicting or inconsistent uses of that RRTYPE and data field. 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 September 02, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 Klensin, Sullivan & FalExpires September 02, 2014 [Page 1] Internet-Draft TXT RR Data Registry March 2014 2. Registry Contents . . . . . . . . . . . . . . . . . . . . . . 3 3. Adding New Registry Entries . . . . . . . . . . . . . . . . . 3 4. Updating Registry Entries . . . . . . . . . . . . . . . . . . 3 5. Registraton Template . . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 Appendix A. DNS Parameter and Registry Loose Ends . . . . . . . . 6 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . . 7 Appendix B.1. Changes from version -00 to -01 . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The TXT RRTYPE was defined as part of the initial domain name system (DNS) specification [RFC1035] to hold descriptive text the semantics of which was to be dependent on the domain in which the TXT record was found (paraphrase of part of Section 3.3.14 of RFC 1035). In more recent years, several protocols have used the TXT RRTYPE for structured information to be used by particular protocols, sometimes to avoid creating a separate and specific RRTYPE. There have been extensive discussions about whether that type of use of the TXT RRTYPE is appropriate or desirable; design choices about DNS extensions and some of their consequences are discussed in RFC 5507 [RFC5507]. However, independent of how one feels about those issues, the reality is that the DATA fields of TXT RRs are in use for protocol-specific information that is interpreted by the protocols themselves. Those uses are not going to disappear. It is even possible that tradeoffs between established uses, conversion costs, and related issue might justify standardization of the practice, however problematic and/or distasteful that might be in principle. Having structured information that is protocol-specific without a registry increases the risk of different parties using the same identifying information for different purposes, thereby creating security and operational risks. This document specifies the relevant registry. It might be argued that a registry is inappropriate, because it is in effect a subtyping of the TXT RRTYPE. While the position has merit, without a registry and with continued uses of TXT to support pieces of protocol, it is only a matter of time before overlapping or confusable uses turn into an attack. While such an outcome might be accidental, it would still be bad. If there were a registry, then one might dream of zone-checking tools that would warn about apparently-structured information that didn't reflect any of the registered entries. It is important to stress that this registry is intrinsically about what is being done and not about what risks exist and whether particular measures or considerations might mitigate those risks. Klensin, Sullivan & FalExpires September 02, 2014 [Page 2] Internet-Draft TXT RR Data Registry March 2014 This document specifies creation of that registry and the means by while it is populated. 2. Registry Contents Each registry entry consists of a reference to the protocol that identifies specific information in the TXT Resource Record's RDATA field and that indicates what information is used to make that identification. For example, if the "foo" protocol were described in RFC 9999 and used the presence of the string "foo=" at the beginning of the first character string in the TXT Resource Record RDATA to identify information that applied to it, the registry would identify the protocol ("foo"), the submitter, the reference that described it ("RFC 9999") and the association-determining string ("foo="). The registry also allows for comment information. That information might include information about prefixes or suffixes for the DNS owner name that are used with the particular protocol at issue. For tracking purposes, each entry also contains date created and date last modified information. 3. Adding New Registry Entries As discussed when the IETF concluded that there should be fewer barriers to the creation and use of new RRTYPES [RFC6895] best practices today generally call for creating new, protocol- or application-specific types rather than overloading information onto the TXT RRTYPE. Consequently, this registry is expected to reflect deployed existing practices rather than new uses for TXT. Its use to make the latter more acceptable would contradict the intent of both this specification and the registry itself. Consistent with that principle, the procedure for accepting new entries into the registry will be review by a Designated Expert [RFC5226] as modified below. The Expert is expected to determine that the particular use of TXT is in established use and, ideally, is documented with a stable specification as defined by RFC 5226 and the RFC Editor. The existence of a standards track RFC or equivalent specification is always sufficient to meet those conditions. In less common cases, the Expert should consider the explanation above and apply good judgment, favoring adding entries to the registry in cases of doubt. Cases that cannot be resolved adequately by discussion between the applicant and the Expert may be referred to the IESG. 4. Updating Registry Entries Klensin, Sullivan & FalExpires September 02, 2014 [Page 3] Internet-Draft TXT RR Data Registry March 2014 Registries may be updated using the same mechanisms used to create new ones. The expert reviewer should attempt to ensure that updates are limited to corrections or consistent expansions of earlier information and that the party proposing the update is at least as authoritative about the original protocol as the party who submitted the original registration request. 5. Registraton Template A registration request should supply the following information, ideally in this form: 1. Name and contact information for the submitter. 2. Protocol identification and, where feasible, documentation reference. 3. Distinguishing characteristics of the TXT RDATA content that permit identifying information for this protocol. 4. Any special considerations for multiple TXT records with the same owner name. 5. Other special constraint or identifying information. For example, if the protocol being registered requires special prefixes or suffixes for the owner name, a discussion of that requirement. 6. IANA Considerations This memo specifies the creation of a new registry in the Domain Name System (DNS) Parameters group [IANA-DNS-Parameters]. The details for the contents and registration requirements for that registry appear in Section 2 and Section 3 above. The registry should have explicit text referencing this document. The text should be similar to the following: "This registry exists to decrease the risk for overlapping use of the TXT Resource Record Type for structured data instead of having the RDATA for that type contain only descriptive text without specified semantics (as described in RFC 1035. See RFC 5507 and the Security Considerations section of RFC NNNN for more information." While it is common practice for registry-creating documents to specify the initial content of the registry, this one deliberately does not do so in order to allow the actual users of the relevant types to identify them and provide explanations for their use. Klensin, Sullivan & FalExpires September 02, 2014 [Page 4] Internet-Draft TXT RR Data Registry March 2014 [[Note in draft: The authors disagree as to whether this document should include all known uses of TXT RRTYPE DATA (specifically including all of those discovered in the surveys conducted in conjunction with the SPFbis work) or should create an empty registry and await addition of entries as described in this specification. The advantage of the former is that the registry will contain a useful list of applications of TXT much more quickly. Via the expert review process, the latter would presumably yield better descriptions and information about responsible parties for many entries. A possible middle ground would be to try to identify all uses that are explicitly identified in IETF standards track documents and include them initially, leaving other uses to the registration process.]] 7. Security Considerations The creation and use of this registry should help to minimize the risks of different protocols inadvertently using data embedded in TXT Resource Records in incompatible ways. Consequently, it should have a positive effect on security. Because this document and the registry do not address the question of what protocols, if any, should use TXT RDATA in this way, questions associated with the usage and structure of particular protocols lie outside its scope. There is a general (although by no means unanimous) view among DNS experts that overloading RRTYPEs, especially the TXT type, is a bad practice that could lead, not only to the sort of conflicts that this registry might help prevent, but to requirements for multiple queries and even an increased risk from amplification attacks. While caution is always appropriate when documenting a risky practice lest the documentation be taken as endorsement, the arguments for providing documentation for deployed protocol uses of TXT RRs seems very similar to the historical arguments for documenting security risks: being secretive about them won't prevent either their being exploited or prevent new ones from being invented. 8. Acknowledgements The requirement for this registry became obvious as a result of the discussion of handing records for SPF in the DNS. The comments of the participants on all sides of that discussion are gratefully acknowledged. Specific comments and text for this draft were provided by Eliot Lear and Subramanian Moonesamy. [[Several useful comments about the general approach taken in the document were received in private notes whose authors may or may not want to be linied to the draft. The originators of such comments should contact the first-listed author if they would like to be listed explicitly.]] 9. References Klensin, Sullivan & FalExpires September 02, 2014 [Page 5] Internet-Draft TXT RR Data Registry March 2014 9.1. Normative References [IANA-DNS-Parameters] IANA, "Domain Name System (DNS) Parameters", 2013, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 9.2. Informative References [RFC5507] IAB, Faltstrom, P., Austein, R. and P. Koch, "Design Choices When Expanding the DNS", RFC 5507, April 2009. [RFC6895] Eastlake, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, April 2013. Appendix A. DNS Parameter and Registry Loose Ends [[RFC Editor: please remove this appendix before publication.]] The discussions surrounding this draft suggest that one or two additional DNS registries may be needed and that the current IANA structure for DNS-related information may not be optimal. In particular, there is no registry for two of the five extension mechanisms described in RFC 5507 as adding prefix or suffixes to owner names. In that context, the registry proposed in this specification can be seen as essentially a subtype registry for the TXT RRTYPE altnough it is deliberately designed to include TXT- related prefixes and suffix approaches as well. It would, however, probably be useful for someone to investigate and, if appropriate, specify additional subtype, prefix, and suffix registries as appropriate. As part of that effort, it may be useful to advise IANA as to whether some or all of the registries at https://www.iana.org/assignments/s-naptr-parameters/s-naptr- parameters.xhtml, https://www.iana.org/assignments/sip-table/sip-table.xhtml, https://www.iana.org/assignments/enum-services/enum- services.xhtml, https://www.iana.org/assignments/im-srv-labels/im-srv- labels.xhtml, Klensin, Sullivan & FalExpires September 02, 2014 [Page 6] Internet-Draft TXT RR Data Registry March 2014 https://www.iana.org/assignments/pres-srv-labels/pres-srv- labels.xhtml, https://www.iana.org/assignments/service-names-port-numbers/ service-names-port-numbers.xhtml, and https://www.iana.org/assignments/pkix-parameters/pkix- parameters.xhtml Should be incorporated into, or have crossreference links from, the IANA "Domain Name System (DNS) Parameters" page. Appendix B. Change Log [[RFC Editor: Please remove this appendix before publication.]] Appendix B.1. Changes from version -00 to -01 o Added this appendix o Corrected the statement about the absence of an SRV label registry and added that registry to the Appendix Appendix A list. o Small formatting changes to improve readability. o Replaced the discussion among the authors in Section 6 with a summary note. Community input is needed. Authors' Addresses John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA Phone: +1 617 245 1457 Email: john-ietf@jck.com Andrew Sullivan Dyn 150 Dow St Manchester, NH 03101 USA Email: asullivan@dyn.com Klensin, Sullivan & FalExpires September 02, 2014 [Page 7] Internet-Draft TXT RR Data Registry March 2014 Patrik Faltstrom Netnod Franzengatan 5 112 51 Stockholm, Sweden Email: paf@netnod.se Klensin, Sullivan & FalExpires September 02, 2014 [Page 8]