--- /dev/null
+
+
+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 <namedroppers@ops.ietf.org> 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]
+
projects / thirdparty / bind9.git / commitdiff
