[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/