DNS Extensions Working Group R. Arends Internet-Draft Telematica Instituut Expires: April 25, 2005 P. Koch Universitaet Bielefeld J. Schlyter NIC-SE October 25, 2004 Evaluating DNSSEC Transition Mechanisms draft-ietf-dnsext-dnssec-trans-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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 April 25, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document collects and summarizes different proposals for alternative and additional strategies for authenticated denial in DNS responses, evaluates these proposals and gives a recommendation for a way forward. Arends, et al. Expires April 25, 2005 [Page 1] Internet-Draft Evaluating DNSSEC Transition Mechanisms October 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3 2.1 Mechanisms Updating DNSSEC-bis . . . . . . . . . . . . . . 4 2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4 2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . 4 2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . 5 2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . 6 2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . 7 2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . 8 2.2 Mechanisms not Updating DNSSEC-bis . . . . . . . . . . . . 9 2.2.1 Partial Type-code and Signal Rollover . . . . . . . . 9 2.2.2 A Complete Type-code and Signal Rollover . . . . . . . 9 2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 10 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 13 Arends, et al. Expires April 25, 2005 [Page 2] Internet-Draft Evaluating DNSSEC Transition Mechanisms October 2004 1. Introduction The working group consents on not including NSEC-alt in the DNSSEC-bis documents. The working group considers to take up "prevention of zone enumeration" as a work item. There may be multiple mechanisms to allow for co-existence with DNSSEC-bis. The chairs allow the working group a little over a week (up to June 12) to come to consensus on a possible modification to the document to enable gentle rollover. If that consensus cannot be reached the DNSSEC-bis documents will go out as-is. To ease the process of getting consensus, a summary of the proposed solutions and analysis of the pros and cons were written during the weekend. This summary includes: An inventory of the proposed mechanisms to make a transition to future work on authenticated denial of existence. List the known Pros and Cons, possibly provide new arguments, and possible security considerations of these mechanisms. Provide a recommendation on a way forward that is least disruptive to the DNSSEC-bis specifications as they stand and keep an open path to other methods for authenticated denial existence. The descriptions of the proposals in this document are coarse and do not cover every detail necessary for implementation. In any case, documentation and further study is needed before implementaion and/or deployment, including those which seem to be solely operational in nature. 2. Transition Mechanisms In the light of recent discussions and past proposals, we have found several ways to allow for transition to future expansion of authenticated denial. We tried to illuminate the paths and pitfalls in these ways forward. Some proposals lead to a versioning of DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other proposals are 'clean' but may cause delay, while again others may be plain hacks. Some paths do not introduce versioning, and might require the current DNSSEC-bis documents to be fully updated to allow for extensions to authenticated denial mechanisms. Other paths introduce versioning and do not (or minimally) require DNSSEC-bis documents to be updated, allowing DNSSEC-bis to be deployed, while future versions can be drafted independent from or partially depending on DNSSEC-bis. Arends, et al. Expires April 25, 2005 [Page 3] Internet-Draft Evaluating DNSSEC Transition Mechanisms October 2004 2.1 Mechanisms Updating DNSSEC-bis 2.1.1 Dynamic NSEC Synthesis This proposal assumes that NSEC RRs and the authenticating RRSIG will be generated dynamically to just cover the (non existent) query name. The owner name is (the) one preceding the name queried for, the Next Owner Name Field has the value of the Query Name Field + 1 (first successor in canonical ordering). A separate key (the normal ZSK or a separate ZSK per authoritative server) would be used for RRSIGs on NSEC RRs. This is a defense against enumeration, though it has the presumption of online signing. 2.1.1.1 Coexistence and Migration There is no change in interpretation other then that the next owner name might or might not exist. 2.1.1.2 Limitations This introduces an unbalanced cost between query and response generation due to dynamic generation of signatures. 2.1.1.3 Amendments to DNSSEC-bis The current DNSSEC-bis documents might need to be updated to indicate that the next owner name might not be an existing name in the zone. This is not a real change to the spec since implementers have been warned not to synthesize with previously cached NSEC records. A specific bit to identify the dynamic signature generating Key might be useful as well, to prevent it from being used to fake positive data. 2.1.1.4 Cons Unbalanced cost is a ground for DDoS. Though this protects against enumeration, it is not really a path for versioning. 2.1.1.5 Pros Hardly any amendments to DNSSEC-bis. 2.1.2 Add Versioning/Subtyping to Current NSEC This proposal introduces versioning for the NSEC RR type (a.k.a. subtyping) by adding a (one octet) version field to the NSEC RDATA. Version number 0 is assigned to the current (DNSSEC-bis) meaning, making this an 'Must Be Zero' (MBZ) for the to be published docset. Arends, et al. Expires April 25, 2005 [Page 4] Internet-Draft Evaluating DNSSEC Transition Mechanisms October 2004 2.1.2.1 Coexistence and Migration Since the versioning is done inside the NSEC RR, different versions may coexist. However, depending on future methods, that may or may not be useful inside a single zone. Resolvers cannot ask for specific NSEC versions but may be able to indicate version support by means of a to be defined EDNS option bit. 2.1.2.2 Limitations There are no technical limitations, though it will cause delay to allow testing of the (currently unknown) new NSEC interpretation. Since the versioning and signaling is done inside the NSEC RR, future methods will likely be restricted to a single RR type authenticated denial (as opposed to e.g. NSEC-alt, which currently proposes three RR types). 2.1.2.3 Amendments to DNSSEC-bis Full Update of the current DNSSEC-bis documents to provide for new fields in NSEC, while specifying behavior in case of unknown field values. 2.1.2.4 Cons Though this is a clean and clear path without versioning DNSSEC, it takes some time to design, gain consensus, update the current dnssec-bis document, test and implement a new authenticated denial record. 2.1.2.5 Pros Does not introduce an iteration to DNSSEC while providing a clear and clean migration strategy. 2.1.3 Type Bit Map NSEC Indicator Bits in the type-bit-map are reused or allocated to signify the interpretation of NSEC. This proposal assumes that future extensions make use of the existing NSEC RDATA syntax, while it may need to change the interpretation of the RDATA or introduce an alternative denial mechanism, invoked by the specific type-bit-map-bits. Arends, et al. Expires April 25, 2005 [Page 5] Internet-Draft Evaluating DNSSEC Transition Mechanisms October 2004 2.1.3.1 Coexistence and migration Old and new NSEC meaning could coexist, depending how the signaling would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR types are available as well as those covering meta/query types or types to be specifically allocated. 2.1.3.2 Limitations This mechanism uses an NSEC field that was not designed for that purpose. Similar methods were discussed during the Opt-In discussion and the Silly-State discussion. 2.1.3.3 Amendments to DNSSEC-bis The specific type-bit-map-bits must be allocated and they need to be specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis) interpretation. Also, behaviour of the resolver and validator must be documented in case unknown values are encountered for the MBZ field. Currently the protocol document specifies that the validator MUST ignore the setting of the NSEC and the RRSIG bits, while other bits are only used for the specific purpose of the type-bit-map field 2.1.3.4 Cons The type-bit-map was not designed for this purpose. It is a straightforward hack. Text in protocol section 5.4 was put in specially to defend against this usage. 2.1.3.5 Pros No change needed to the on-the-wire protocol as specified in the current docset. 2.1.4 New Apex Type This introduces a new Apex type (parallel to the zone's SOA) indicating the DNSSEC version (or authenticated denial) used in or for this zone. 2.1.4.1 Coexistence and Migration Depending on the design of this new RR type multiple denial mechanisms may coexist in a zone. Old validators will not understand and thus ignore the new type, so interpretation of the new NSEC scheme may fail, negative responses may appear 'bogus'. Arends, et al. Expires April 25, 2005 [Page 6] Internet-Draft Evaluating DNSSEC Transition Mechanisms October 2004 2.1.4.2 Limitations A record of this kind is likely to carry additional feature/versioning indications unrelated to the current question of authenticated denial. 2.1.4.3 Amendments to DNSSEC-bis The current DNSSEC-bis documents need to be updated to indicate that the absence of this type indicates dnssec-bis, and that the (mere) presence of this type indicated unknown versions. 2.1.4.4 Cons The only other 'zone' or 'apex' record is the SOA record. Though this proposal is not new, it is yet unknown how it might fulfill authenticated denial extensions. This new RR type would only provide for a generalized signaling mechanism, not the new authenticated denial scheme. Since it is likely to be general in nature, due to this generality consensus is not to be reached soon. 2.1.4.5 Pros This approach would allow for a lot of other per zone information to be transported or signaled to both (slave) servers and resolvers. 2.1.5 NSEC White Lies This proposal disables one part of NSEC (the pointer part) by means of a special target (root, apex, owner, ...), leaving intact only the ability to authenticate denial of existence of RR sets, not denial of existence of domain names (NXDOMAIN). It may be necessary to have one working NSEC to prove the absence of a wildcard. 2.1.5.1 Coexistence and Migration The NSEC target can be specified per RR, so standard NSEC and 'white lie' NSEC can coexist in a zone. There is no need for migration because no versioning is introduced or intended. 2.1.5.2 Limitations This proposal breaks the protocol and is applicable to certain types of zones only (no wildcard, no deep names, delegation only). Most of the burden is put on the resolver side and operational consequences are yet to be studied. Arends, et al. Expires April 25, 2005 [Page 7] Internet-Draft Evaluating DNSSEC Transition Mechanisms October 2004 2.1.5.3 Amendments to DNSSEC-bis The current DNSSEC-bis documents need to be updated to indicate that the NXDOMAIN responses may be insecure. 2.1.5.4 Cons Strictly speaking this breaks the protocol and doesn't fully fulfill the requirements for authenticated denial of existence. Security implications need to be carefully documented: search path problems (forged denial of existence may lead to wrong expansion of non-FQDNs, cf. RFC 1535); replay attacks to deny existence of records 2.1.5.5 Pros Hardly any amendments to DNSSEC-bis. Operational "trick" that is available anyway. 2.1.6 NSEC Optional via DNSSKEY Flag A new DNSKEY may be defined to declare NSEC optional per zone. 2.1.6.1 Coexistence and Migration Current resolvers/validators will not understand the Flag bit and will have to treat negative responses as bogus. Otherwise, no migration path is needed since NSEC is simply turned off. 2.1.6.2 Limitations NSEC can only be made completely optional at the cost of being unable to prove unsecure delegations (absence of DS RR). A next to this approach would just disable authenticated denial for non-existence of nodes. 2.1.6.3 Amendments to DNSSEC-bis New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to be specified in the light of absence of authenticated denial. 2.1.6.4 Cons Doesn't fully meet requirements. Operational consequences to be studied. 2.1.6.5 Pros Official version of the "trick" presented in (8). Operational Arends, et al. Expires April 25, 2005 [Page 8] Internet-Draft Evaluating DNSSEC Transition Mechanisms October 2004 problems can be addressed during future work on validators. 2.2 Mechanisms not Updating DNSSEC-bis 2.2.1 Partial Type-code and Signal Rollover Carefully crafted type code/signal rollover to define a new authenticated denial space that extends/replaces DNSSEC-bis authenticated denial space. This particular path is illuminated by Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com> posted to 2004-06-02. 2.2.1.1 Coexistence and Migration To protect the current resolver for future versions, a new DNSSEC-OK bit must be allocated to make clear it does or does not understand the future version. Also, a new DS type needs to be allocated to allow differentiation between a current signed delegation and a 'future' signed delegation. Also, current NSEC needs to be rolled into a new authenticated denial type. 2.2.1.2 Limitations None. 2.2.1.3 Amendments to DNSSEC-bis None. 2.2.1.4 Cons It is cumbersome to carefully craft an TCR that 'just fits'. The DNSSEC-bis protocol has many 'borderline' cases that needs special consideration. It might be easier to do a full TCR, since a few of the types and signals need upgrading anyway. 2.2.1.5 Pros Graceful adoption of future versions of NSEC, while there are no amendments to DNSSEC-bis. 2.2.2 A Complete Type-code and Signal Rollover A new DNSSEC space is defined which can exist independent of current DNSSEC-bis space. This proposal assumes that all current DNSSEC type-codes (RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any Arends, et al. Expires April 25, 2005 [Page 9] Internet-Draft Evaluating DNSSEC Transition Mechanisms October 2004 future versions of DNSSEC. Any future version of DNSSEC has its own types to allow for keys, signatures, authenticated denial, etcetera. 2.2.2.1 Coexistence and Migration Both spaces can co-exist. They can be made completely orthogonal. 2.2.2.2 Limitations None. 2.2.2.3 Amendments to DNSSEC-bis None. 2.2.2.4 Cons With this path we abandon the current DNSSEC-bis. Though it is easy to role specific well-known and well-tested parts into the re-write, once deployment has started this path is very expensive for implementers, registries, registrars and registrants as well as resolvers/users. A TCR is not to be expected to occur frequently, so while a next generation authenticated denial may be enabled by a TCR, it is likely that that TCR will only be agreed upon if it serves a whole basket of changes or additions. A quick introduction of NSEC-ng should not be expected from this path. 2.2.2.5 Pros No amendments/changes to current DNSSEC-bis docset needed. It is always there as last resort. 2.2.3 Unknown Algorithm in RRSIG This proposal assumes that future extensions make use of the existing NSEC RDATA syntax, while it may need to change the interpretation of the RDATA or introduce an alternative denial mechanism, invoked by the specific unknown signing algorithm. The different interpretation would be signaled by use of different signature algorithms in the RRSIG records covering the NSEC RRs. When an entire zone is signed with a single unknown algorithm, it will cause implementations that follow current dnssec-bis documents to treat individual RRsets as unsigned. 2.2.3.1 Coexistence and migration Old and new NSEC RDATA interpretation or known and unknown Signatures Arends, et al. Expires April 25, 2005 [Page 10] Internet-Draft Evaluating DNSSEC Transition Mechanisms October 2004 can NOT coexist in a zone since signatures cover complete (NSEC) RRSets. 2.2.3.2 Limitations Validating resolvers agnostic of new interpretation will treat the NSEC RRset as "not signed". This affects wildcard and non-existence proof, as well as proof for (un)secured delegations. Also, all positive signatures (RRSIGs on RRSets other than DS, NSEC) appear insecure/bogus to an old validator. The algorithm version space is split for each future version of DNSSEC. Violation of the 'modular components' concept. We use the 'validator' to protect the 'resolver' from unknown interpretations. 2.2.3.3 Amendments to DNSSEC-bis None. 2.2.3.4 Cons The algorithm field was not designed for this purpose. This is a straightforward hack. 2.2.3.5 Pros No amendments/changes to current DNSSEC-bis docset needed. 3. Recommendation The authors recommend that the working group commits to and starts work on a partial TCR, allowing gracefull transition towards a future version of NSEC. Meanwhile, to accomodate the need for an immediately, temporary, solution against zone-traversal, we recommend On-Demand NSEC synthesis. This approach does not require any mandatory changes to DNSSEC-bis, does not violate the protocol and fulfills the requirements. As a side effect, it moves the cost of implementation and deployment to the users (zone owners) of this mechanism. Arends, et al. Expires April 25, 2005 [Page 11] Internet-Draft Evaluating DNSSEC Transition Mechanisms October 2004 Authors' Addresses Roy Arends Telematica Instituut Drienerlolaan 5 Enschede 7522 NB Netherlands Phone: +31 534850485 EMail: roy.arends@telin.nl Peter Koch Universitaet Bielefeld Bielefeld 33594 Germany Phone: +49 521 106 2902 EMail: pk@TechFak.Uni-Bielefeld.DE Jakob Schlyter NIC-SE Box 5774 Stockholm SE-114 87 Sweden EMail: jakob@nic.se URI: http://www.nic.se/ Arends, et al. Expires April 25, 2005 [Page 12] Internet-Draft Evaluating DNSSEC Transition Mechanisms October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Arends, et al. Expires April 25, 2005 [Page 13]