diff --git a/doc/draft/draft-ietf-dnsext-dnssec-trans-00.txt b/doc/draft/draft-ietf-dnsext-dnssec-trans-00.txt new file mode 100644 index 0000000000..94ff297f8a --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-trans-00.txt @@ -0,0 +1,784 @@ + + +DNS Extensions Working Group R. Arends +Internet-Draft Telematica Instituut +Expires: December 7, 2004 P. Koch + Universitaet Bielefeld + J. Schlyter + NIC-SE + June 8, 2004 + + + Evaluating DNSSEC Transition Mechanisms + draft-ietf-dnsext-dnssec-trans-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 December 7, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +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 December 7, 2004 [Page 1] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms June 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 December 7, 2004 [Page 2] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms June 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 December 7, 2004 [Page 3] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms June 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 December 7, 2004 [Page 4] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms June 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 December 7, 2004 [Page 5] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms June 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 December 7, 2004 [Page 6] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms June 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 December 7, 2004 [Page 7] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms June 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 December 7, 2004 [Page 8] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms June 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 future + + + +Arends, et al. Expires December 7, 2004 [Page 9] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 + + + 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 December 7, 2004 [Page 10] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms June 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 December 7, 2004 [Page 11] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms June 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 December 7, 2004 [Page 12] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms June 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 + + + +Arends, et al. Expires December 7, 2004 [Page 13] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms June 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires December 7, 2004 [Page 14] +