Internet-Draft E. Lewis Individual Submission NAI Labs Expires: August 13, 2002 February 15, 2002 Discussing Application Public Keys in the DNS draft-lewis-siked-dnsargs-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 15, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract A debate over whether to include public keys for other applications in the Domain Name System has been held ever since the introduction of the DNS Security Extensions. This document records the salient points of the debate. 1 Introduction The Domain Name System [rfc 1034, 1035], lacking sufficient security, lead to the DNS Security Extensions [rfc 2535]. One of the elements of the Extensions is a resource record called the KEY RR. The KEY RR provided the means to store and distribute a public key within the DNS. One of the ideas promoted early in the development of the DNS Security Extensions is the notion that the KEY RR could be used by applications, that is other than DNS, to store and retrieve keys. This would be done leveraging the protection now offered to DNS data. One other resource record that added a bit to the discussion is the CERT RR [rfc 2538]. This record was defined expressly for the use of non-DNS applications. Each CERT RR is defined to hold the bytes of a certificate, leaving the definition of a certificate and the format of the data to the field indicating the type of the certificate. E.g., PGP or X.509. As the idea of putting so called "application keys" in DNS became more developed, and as the DNS Security Extensions became more developed, the appropriateness of this idea came under scrutiny. In this document the issues that appeared on the mail list are summarized. The reason for doing this is to record the debate in a more concise manner and, more importantly, provide bounds for application key distribution and DNS. 2 Reasons For The reasons for placing application keys into DNS, with protection via DNSSEC are largely based on the assumption that DNS is already there, and will always be there. 2.1 DNS As Enabler In order to have a presence on the network, as in a small organization maintaining a web site, there must be a DNS name server somewhere. DNS is a minimum barrier to entry on the network, so it is a given than it will be run, or run via a contract. Other network services may be offered, but none of them is needed for DNS. DNS is the entry point. Therefore, placing application keys in DNS is a path of least resistance. Any alternative to DNS means running that service too. 2.2 DNS Is As Reliable As Anything In as much as DNS is the entry point into an organization's resources, when the DNS is down, the network is down. This is a coarse generalization, meaning that if you put data into the DNS, it will be as available as the ability to find the application that would use the key. While DNS is not perfect when it comes to being a reliable system, using any other means to distribute keys is only going to be as reliable or worse. It is possible that access to a resource is still possible with the DNS down, e.g., decrypting an already received email is possible even if the sender's DNS is down. However, the key is already in hand, accessing the key would be hurt by the DNS outage. 2.3 DNS Is Suited For The Job (Code Reuse) DNS is a look up based system. Data is retrieved based upon a class, name, and type. If the data is there, the data is returned. If the data isn't there, then a no-data answer is returned. Applications will be able to know exactly where the keys they require are. For example, in SSH, the keys should be located at or near the address record for the server being contacted. The look up for the key should be as simple as the look up for the address. 3 Reasons Against The reasons against placing application keys in DNS are fundamentally rooted in protecting the critical resource that DNS is. 3.1 Response Size Overflow Perhaps the most critical impact of application keys in DNS is a result of their large size. DNS relies on using UDP datagrams for efficient delivery of data. No matter what the size of the datagrams is, loading application keys into DNS will cause the size of certain responses to overflow the UDP boundary. Although steps can be taken to mitigate this, it is inevitable that somewhere the overflow will happen. (Note that DNS overflow may happen for other reasons, but they are beyond the scope of this argument.) The result of the overflow is a fall back to TCP. Using TCP incurs a much higher overhead than UDP, with this overhead impacting a DNS server. The impact will not be good, at best slowing down a critical server. 3.2 Zone Administrator Already Busy Assuming the security of the application key is provided via DNSSEC verification of the KEY RR holding it, there are two consequences. One is that the zone administrator is now responsible for the zone's health and safety but also the safety of applications running on all the hosts represented in the zone. This can prove to be quite a bit of mission-creep for the administrator. The other consequence is in the next section. It has been noted that a zone administrator is already responsible for the A record, and a wrong A record would have undesired consequences. The reason KEY records are thought to be more sensitive is that there is an implied liability attached to data meant to secure or, in essence, guarantee data. 3.3. Breaking a DNS Key Breaks Application Keys Assuming the application is trusting DNSSEC to protect the key, then the application is vulnerable to a breaking (exposure, etc) of any of the DNSSEC keys used to validate the data delivered to the application. 3.4 Volume of Data Besides the response size issue, the sheer volume of queries and responses for application keys is bound to stress the DNS. More stress will lead to more problems and possibly down time. [Editorial note: During the review of this text, this point was called into question. I'd appreciate if someone felt that this explanation should be strengthened or dropped.] 3.5 NAPTR record DNS shouldn't hold the keys, but it can be a starting place to find them. There already exists a resource record for referring to other services, and it is called NAPTR (rfc 2915). NAPTR isn't a ready solution, but it is a start, and a potentially a paradigm for using DNS to find fragmented data services. 4 Summary This document is intended to capture the results of an already held, heated debate. Comment on the claims here should be directed at correcting inaccuracies, not debating the merits. This document is also not attempting to draw a conclusion from the arguments presented. 5 Security Considerations This document does not have any direct impact on security is as much as the document is just a summary of a discussion. 6 IANA Considerations There are no requests of nor recommendations to IANA in this document. References [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2538] Eastlake, D., "Storing Certificates in the Domain Name System (DNS)", RFC 2538, March 1999. [RFC2915] Mealling, M., "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000. Editor's Address Edward Lewis NAI Labs 3060 Washington Rd. (Rte 97) Glenwood, MD, 21738 USA EMail: firstname.lastname@example.org Appendix A. Acknowledgements The author gratefully acknowledges, in no particular order, the contributions of the following persons: Jakob Schlyter members of the namedroppers mailing list Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.