DNSOP R. Gieben Internet-Draft NLnet Labs Expires: July 1, 2004 G. Guette IRISA / INRIA O. Courtay ENST-Bretagne January 2004 DNSSEC Resolver Interface to Applications draft-ietf-dnsop-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 July 1, 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 wants to know from a secure aware resolver?". In section 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 Gieben, et al. Expires July 1, 2004 [Page 1] Internet-Draft DNSSEC Resolver Interface to Applications January 2004 control on what to do with bogus data. 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? . . . . . . . . . . . . 7 6. Interface to the Resolver . . . . . . . . . . . . . . . . . . . 7 7. Resolver Interface on The Network . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 Normative References . . . . . . . . . . . . . . . . . . . . . . 7 Informative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 A. Document Details and Changes . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . 9 Gieben, et al. Expires July 1, 2004 [Page 2] Internet-Draft DNSSEC Resolver Interface to Applications January 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 application interact in a DNSSEC World. This document intends to start a discussion about on how such a possible interface between application and resolver might look like and if it is desirable. The structure of the document is as follows. [Editors Note: need to say something here.] 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 still could be useful depending on the reason why it is bogus and what the intentions are of the end-user. 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.] Gieben, et al. Expires July 1, 2004 [Page 3] Internet-Draft DNSSEC Resolver Interface to Applications January 2004 o Fully DNSSEC Aware Resolver (FDAR): 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 to be assumed an entity that communicates with a resolver. o Cache: An entity that stores Resource Records for the duration of their TTL. We could go as far to merge a resolver (FDAR) and a cache and which case you get a "Fully DNSSEC Aware Caching Resolver", that would yield FDACR, which is unpronounceable, so may be FDARC is better (Fully DNSSEC Aware Resolver and Caching). 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 get 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 getting bogus could be of importance to an application. We can distinguish between the following: 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. 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.] o Timing issue Gieben, et al. Expires July 1, 2004 [Page 4] Internet-Draft DNSSEC Resolver Interface to Applications January 2004 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 corresponds to specific errors. After a query multiple bits may be set to 1. [Editors Note: Is all bits set to 0 possible or forbidden?] The bit array has a length of 32 bits. [Editors Note: If 32 bits is too little we use 64.] The right most bit is numbered 0 and the left most if numbered 31. The left most two bits of these array have a slightly different meaning. Bit 31 will tell an application if the entire answer is validated (1) or not (0). Bit 30 is used to signal if the data was gathered with a (insecure) DNS lookup (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: [Editors Note: This is a very rough sketch of a possible filling.] Gieben, et al. Expires July 1, 2004 [Page 5] Internet-Draft DNSSEC Resolver Interface to Applications January 2004 Bit # | Definition Bit # | Definition 0 KEY RR is missing 16 1 DS RR is missing 17 2 NSEC RR is missing 18 3 SIG RR is missing 19 4 Other RR is missing 20 5 SIG does not match 21 6 SIG is expired 22 7 SIG is not yet valid 23 8 Delegation problem DS/KEY 24 9 Delegation problem NS 25 Bad algorithm 10 26 KEY size not accepted 11 27 12 28 13 29 General Failure 14 30 1 if insecure 15 31 1 if validated The first four bits define the resource records used for the validation of the chain of trust. When one of this bit is set to 1, it means that record is missing (i.e. could not be retrieved). The fifth bit means that a record not mentioned above is missing. Bits 5, 6 and 7 concern a signature problem. Bit 5 means that the signature of the RRset does not match the retrieved RRSIG. Bits 6 and 7 means that the signature is expired or that the signature is not yet valid. There is no need to specify a bit for the case we have no key corresponding to the key ID present in the RRSIG, because this is a missing KEY problem (bit 0). Bit 8 and 9 are about delegation problems. Bit 8 means that no DS of the parent zone referenced a DNSKEY in the child zone. Bit 9 means there is a delegation problem. The last block of bits deals with less severe problems and local policy. Bit 25 means that the algorithm used to generate the signature is not accepted by the resolver. The meaning of bit 26 is that for security reasons that the DNSKEY size is not accepted (either too long or too short). [Editors Note: Bit 29 to start discussion, bit for all other type of error. Is this needed?] Gieben, et al. Expires July 1, 2004 [Page 6] Internet-Draft DNSSEC Resolver Interface to Applications January 2004 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 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 Normative References 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 July 1, 2004 [Page 7] Internet-Draft DNSSEC Resolver Interface to Applications January 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 July 1, 2004 [Page 8] Internet-Draft DNSSEC Resolver Interface to Applications January 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 July 1, 2004 [Page 9] Internet-Draft DNSSEC Resolver Interface to Applications January 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 July 1, 2004 [Page 10]