Network Working Group R. Gieben Internet-Draft NLnet Labs Expires: October 19, 2004 G. Guette IRISA / INRIA O. Courtay ENST-Bretagne April 20, 2004 DNSSEC Resolver Interface to Applications draft-gieben-resolver-application-interface-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 October 19, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes an interface between a DNSSEC aware resolver and an application. This interface will define which kind of information a DNSSEC aware resolver is able to send back to an application. The basic question we want to answer is: "What does an application want to know from a secure aware resolver?". In Section 4 we define an error bit array. The secure aware resolver will set specific bits in the array. With the added information in the error array, the application can have extra control on what to do Gieben, et al. Expires October 19, 2004 [Page 1] Internet-Draft DNSSEC Resolver Interface to Applications April 2004 with bogus data. When something goes wrong during the secure resolving process the application may also want to know where in the DNS tree this happened. With a simple error array one can not convey this information. A possibility might be to give the application the owner name of the DNS node where the validation failed. This document is written in the hope that it will lead to a discussion within the IETF on the resolver-application interaction(s). Table of Contents 1. Introduction and Rational . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. What Causes Data to be Bogus? . . . . . . . . . . . . . . . . 4 4. Resolver Interface to Applications . . . . . . . . . . . . . . 5 5. What is Local Policy To an Application? . . . . . . . . . . . 6 6. Interface to the Resolver . . . . . . . . . . . . . . . . . . 7 7. Resolver Interface on The Network . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 7 9.2 Informative References . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 A. Document Details and Changes . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 9 Gieben, et al. Expires October 19, 2004 [Page 2] Internet-Draft DNSSEC Resolver Interface to Applications April 2004 1. Introduction and Rational The server side of DNSSEC is currently well understood. What is lacking is a precise definition on how resolvers and applications interact in a DNSSEC world. This document intends to kick start a discussion about how a possible interface between application and resolver might look like and if it is desirable. We are not going to talk about caching, nor are we detailing an interface protocol for over the network, ie. no protocol modifications are proposed in this document (yet). See Section 7 for details. With DNSSEC we can distinguish between verified, unsecured and bogus data (See [1]). However, if data is bogus it could still be useful depending on why it is bogus and what the intentions of the end-user are. For example, an end-user is browsing a site called banking.example.com. This URL is considered bogus by the local resolver. If the end-user just wants to browse the site the bogus-ness could be considered harmless. If on the other hand the end-user wants to engage in online banking it would be better to postpone that. To make this a reality the browser should be able to show the end-user a pop-up and explain what the problem is. For the browser to do that it would have to know the exact reason on why the data is bogus. The current model (SERVFAIL when data is bogus) is not sufficient for an application to make this decision. In essence the decision is already made (SERVFAIL). Without some standard way of getting this information to an application, different applications will follow different paths to try to get this information somehow. This could lead to the (undesirable) situation where every networked application has its own secure resolver. 2. Definitions [Editors Note: the abbreviations here are given to try to standardize those as well in one swoop. If there is a lot of discussion about it, the will be removed.] o fully DNSSEC Aware Resolver (DAR): Gieben, et al. Expires October 19, 2004 [Page 3] Internet-Draft DNSSEC Resolver Interface to Applications April 2004 A resolver that is fully DNSSEC aware. It implements all DNSSEC mechanism and is capable of querying the DNS (recursively). It has no (permanent) cache. o Application: In this document an application is an entity that sits between an end-user and the resolver. o Cache: An entity that stores Resource Records for the duration of their TTL. We could go as far to merge a resolver (DAR) and a cache and which case you get a "fully DNSSEC Aware Caching Resolver", that would yield DACR, which is unpronounceable, so may be DARC is better (DNSSEC Aware Resolver and Cacher). 3. What Causes Data to be Bogus? There are many ways in DNSSEC for data to become bogus. In this section we classify the different reasons why a resource record set (RR set) can become bogus. Data in DNSSEC is considered bogus when there is no valid chain of trust up to a trusted DNSKEY. As explained above, the exact reason for data becoming bogus could be of importance to an application. We can distinguish between the following causes: bogus due to an attack, bogus due to mis-configuration, bogus due to a timing issue or bogus due to local policy. o Attacks In the case of an attack it is important that a resolver detects this (and reports it to the user). There are many attacks possible. We list some of them below. Some resource records are missing in the answer received by the resolver, possibly because these records are spoofed away by an attacker. Introduction of extra records. An attacker can add wrong RRSIG records. These records can be added in messages from secure zones, but also in messages from otherwise unsecured zones. Another avenue of attacks might be tricking the resolver into believing it is resolving in the unsecure tree, while in fact the tree is secured. o Mis-configuration [Editors Note: What kind of things can we expect here? Missing KEY records....Important thing here: it that it would be nice if we could distinguish between a misconfiguration and an attack. If you know it is missing, it is an attack. Otherwise a misconfiguration is also a possibility.] Gieben, et al. Expires October 19, 2004 [Page 4] Internet-Draft DNSSEC Resolver Interface to Applications April 2004 o Timing issue When a RRset together with its RRSIG is validated by a resolver the first thing checked is the RRSIG expiration and inception time. If the current time does not fall in the interval set by those two times a RRSIG is invalid and the data bogus. It could be conceivable that RRSIG's older than a few minutes are still useful for validation. o Local Policy Decisions Don't accept certain key sizes. Only accept some algorithms. Etc. [Editors Note: Not accepting certain (i.e.) algorithms will thus lead to bogus data, while the DNSSEC crypto may be completely valid.] o Others? [Editors Note: are there more?] 4. Resolver Interface to Applications To signal the resolving status to an application we propose to use an array of bits. This error array will have specific bits set to 1 which correspond to specific errors. After a query multiple bits maybe set to 1. The bit array has a length of 32 bits. [Editors Note: If 32 bits is too little we use 64.] The left most bit is numbered 0 and the right most if numbered 31. The left most two bits of these array have a slightly different meaning. Bit 0 will tell an application if the entire answer is validated (1) or not (0). Bit 1 is used to signal if the data was gathered with one or more (unsecure) DNS query (0) or was done by utilizing DNSSEC (1). If a resolver has a trusted anchor for the current lookup the bit must be set. The definition of the bits is as follows: If the definition is true the bit is set to 1, otherwise the bit is 0. Gieben, et al. Expires October 19, 2004 [Page 5] Internet-Draft DNSSEC Resolver Interface to Applications April 2004 Bit # | Definition Bit # | Definition 0 Unsecure answer 16 AD bit set 1 Validated answer 17 CD bit set 2 Indeterminate 18 3 Missing record 19 4 Delegation problem 20 5 Policy error 21 6 22 7 DS involved 23 Through secure channel 8 NSEC involved 24 Signature timing problem 9 NS involved 25 Bad algorithm 10 RRSIG involved 26 Key size not accepted 11 DNSKEY involved 27 12 28 13 29 14 30 15 31 There are 4 blocks defined in the array, these are: block 1 (bit 0 - bit 5); general indication of any error. Block 2 (bit 7 - bit 11); indicate which RRs are involved in the error. Block 3 (bit 16 - bit 17); what bits are set on the packet and block 4 (bit 23 - bit 26); local policy disapproved the answer. As said, bits 0 and 1 indicate the general failure mode. If bit 0 and bit 1 are both set to 0 an error has occurred. If bit 2 is set, the resolver could not determine the actual cause of the error. When bit 0 and 1 are 0 the other bits in the array should now indicate what the error is. If bit 3 is set, the meaning of the other bits in the array is undefined. Bits 6 up to 10 indicate which RR(s) are involved in the error. Bits 3,4 and 5 indicate what the error is. Bit 3 indicates some records are missing, bit 4 tells the application there was a delegation error and bit 5 says local policy was the culprit. Bit 18 means that the response was obtained though a secure channel. This means the resolver is configured to securely communicate with a forwarder. 5. What is Local Policy To an Application? Local policy is a set of rules which define which bits from the error array can/should be overruled by the application. Local policy defines all the rules that the application must respect, and thus defines the behavior of the application when it receives Gieben, et al. Expires October 19, 2004 [Page 6] Internet-Draft DNSSEC Resolver Interface to Applications April 2004 bogus data or when the verification of the RRset generates an error. 6. Interface to the Resolver In the same way as an application is able to overrule the error array, the user or system administrator can overrule the resolver and thereby influence all applications on a host. This kind of behavior can best be summarized as: "Don't tell the application X", or "Always tell the application X". Where 'X' is the appropriate bit in the error array. 7. Resolver Interface on The Network To send this feedback information over the network would require a protocol extension. We, the authors, think such a extension does not belong in this document. However, for the sake of symmetry such an interface should be defined. Right now we only describe resolver-application behavior on a single host. 8. Acknowledgments The authors would like to thanks the following persons for their contributions to this document (in no particular order): Jelte Jansen, Scott Rose, Suresh Krishnaswamy. 9. References 9.1 Normative References 9.2 Informative References [1] Arends, R., "Protocol Modifications for the DNS Security Extensions", draft-ietf-dnsext-dnssec-protocol-05 (work in progress), March 2003. Authors' Addresses Miek Gieben NLnet Labs Kruislaan 419 Amsterdam 1098 VA NL EMail: miek@nlnetlabs.nl URI: http://www.nlnetlabs.nl Gieben, et al. Expires October 19, 2004 [Page 7] Internet-Draft DNSSEC Resolver Interface to Applications April 2004 Gilles Guette IRISA / INRIA Campus de Beaulieu Rennes 35042 FR EMail: gilles.guette@irisa.fr URI: http://www.irisa.fr Olivier Courtay ENST-Bretagne 2, rue de la chataigneraie Cesson Sevigne 35512 FR EMail: olivier.courtay@enst-bretagne.fr URI: http://www.enst-bretagne.fr Appendix A. Document Details and Changes Gieben, et al. Expires October 19, 2004 [Page 8] Internet-Draft DNSSEC Resolver Interface to Applications April 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 assignees. 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 Gieben, et al. Expires October 19, 2004 [Page 9] Internet-Draft DNSSEC Resolver Interface to Applications April 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Gieben, et al. Expires October 19, 2004 [Page 10]