draft-ietf-dnsext-dnssec-trans-01.txt   draft-ietf-dnsext-dnssec-trans-02.txt 
DNS Extensions Working Group R. Arends DNS Extensions Working Group R. Arends
Internet-Draft Telematica Instituut Internet-Draft Telematica Instituut
Expires: April 25, 2005 P. Koch Expires: August 25, 2005 P. Koch
Universitaet Bielefeld DENIC eG
J. Schlyter J. Schlyter
NIC-SE NIC-SE
October 25, 2004 February 21, 2005
Evaluating DNSSEC Transition Mechanisms Evaluating DNSSEC Transition Mechanisms
draft-ietf-dnsext-dnssec-trans-01.txt draft-ietf-dnsext-dnssec-trans-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2005. This Internet-Draft will expire on August 25, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document collects and summarizes different proposals for This document collects and summarizes different proposals for
alternative and additional strategies for authenticated denial in DNS alternative and additional strategies for authenticated denial in DNS
responses, evaluates these proposals and gives a recommendation for a responses, evaluates these proposals and gives a recommendation for a
way forward. way forward.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3 2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3
2.1 Mechanisms Updating DNSSEC-bis . . . . . . . . . . . . . . 4 2.1 Mechanisms With Need of Updating DNSSEC-bis . . . . . . . 4
2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4 2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4
2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . 4 2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . 5
2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . 5 2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . 6
2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . 6 2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . 6
2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . 7 2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . 7
2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . 8 2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . 8
2.2 Mechanisms not Updating DNSSEC-bis . . . . . . . . . . . . 9 2.1.7 New Answer Pseudo RR Type . . . . . . . . . . . . . . 9
2.2.1 Partial Type-code and Signal Rollover . . . . . . . . 9 2.1.8 SIG(0) Based Authenticated Denial . . . . . . . . . . 9
2.2.2 A Complete Type-code and Signal Rollover . . . . . . . 9 2.2 Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10
2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 10 2.2.1 Partial Type-code and Signal Rollover . . . . . . . . 10
3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.2 A Complete Type-code and Signal Rollover . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 13 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1 Normative References . . . . . . . . . . . . . . . . . . . 13
5.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15
1. Introduction 1. Introduction
This report shall document the process of dealing with the NSEC
walking problem late in the Last Call for
[I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol,
I-D.ietf-dnsext-dnssec-records]. It preserves some of the discussion
as well as some additional ideas that came up subsequently.
This is an edited excerpt of the chairs' mail to the WG:
The working group consents on not including NSEC-alt in the The working group consents on not including NSEC-alt in the
DNSSEC-bis documents. The working group considers to take up DNSSEC-bis documents. The working group considers to take up
"prevention of zone enumeration" as a work item. "prevention of zone enumeration" as a work item.
There may be multiple mechanisms to allow for co-existence with There may be multiple mechanisms to allow for co-existence with
DNSSEC-bis. The chairs allow the working group a little over a week DNSSEC-bis. The chairs allow the working group a little over a
(up to June 12) to come to consensus on a possible modification to week (up to June 12, 2004) to come to consensus on a possible
the document to enable gentle rollover. If that consensus cannot be modification to the document to enable gentle rollover. If that
reached the DNSSEC-bis documents will go out as-is. 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 To ease the process of getting consensus, a summary of the proposed
solutions and analysis of the pros and cons were written during the solutions and analysis of the pros and cons were written during the
weekend. weekend.
This summary includes: This summary includes:
An inventory of the proposed mechanisms to make a transition to An inventory of the proposed mechanisms to make a transition to
future work on authenticated denial of existence. future work on authenticated denial of existence.
List the known Pros and Cons, possibly provide new arguments, and List the known Pros and Cons, possibly provide new arguments, and
possible security considerations of these mechanisms. possible security considerations of these mechanisms.
Provide a recommendation on a way forward that is least disruptive Provide a recommendation on a way forward that is least disruptive
to the DNSSEC-bis specifications as they stand and keep an open to the DNSSEC-bis specifications as they stand and keep an open
path to other methods for authenticated denial existence. path to other methods for authenticated denial of existence.
The descriptions of the proposals in this document are coarse and do The descriptions of the proposals in this document are coarse and do
not cover every detail necessary for implementation. In any case, not cover every detail necessary for implementation. In any case,
documentation and further study is needed before implementaion and/or documentation and further study is needed before implementaion and/or
deployment, including those which seem to be solely operational in deployment, including those which seem to be solely operational in
nature. nature.
2. Transition Mechanisms 2. Transition Mechanisms
In the light of recent discussions and past proposals, we have found In the light of recent discussions and past proposals, we have found
skipping to change at page 4, line 5 skipping to change at page 4, line 13
proposals are 'clean' but may cause delay, while again others may be proposals are 'clean' but may cause delay, while again others may be
plain hacks. plain hacks.
Some paths do not introduce versioning, and might require the current Some paths do not introduce versioning, and might require the current
DNSSEC-bis documents to be fully updated to allow for extensions to DNSSEC-bis documents to be fully updated to allow for extensions to
authenticated denial mechanisms. Other paths introduce versioning authenticated denial mechanisms. Other paths introduce versioning
and do not (or minimally) require DNSSEC-bis documents to be updated, and do not (or minimally) require DNSSEC-bis documents to be updated,
allowing DNSSEC-bis to be deployed, while future versions can be allowing DNSSEC-bis to be deployed, while future versions can be
drafted independent from or partially depending on DNSSEC-bis. drafted independent from or partially depending on DNSSEC-bis.
2.1 Mechanisms Updating DNSSEC-bis 2.1 Mechanisms With Need of Updating DNSSEC-bis
Mechanisms in this category demand updates to the DNSSEC-bis document
set.
2.1.1 Dynamic NSEC Synthesis 2.1.1 Dynamic NSEC Synthesis
This proposal assumes that NSEC RRs and the authenticating RRSIG will This proposal assumes that NSEC RRs and the authenticating RRSIG will
be generated dynamically to just cover the (non existent) query name. be generated dynamically to just cover the (non existent) query name.
The owner name is (the) one preceding the name queried for, the Next 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 Owner Name Field has the value of the Query Name Field + 1 (first
successor in canonical ordering). A separate key (the normal ZSK or successor in canonical ordering). A separate key (the normal ZSK or
a separate ZSK per authoritative server) would be used for RRSIGs on a separate ZSK per authoritative server) would be used for RRSIGs on
NSEC RRs. This is a defense against enumeration, though it has the NSEC RRs. This is a defense against enumeration, though it has the
skipping to change at page 4, line 34 skipping to change at page 4, line 45
This introduces an unbalanced cost between query and response This introduces an unbalanced cost between query and response
generation due to dynamic generation of signatures. generation due to dynamic generation of signatures.
2.1.1.3 Amendments to DNSSEC-bis 2.1.1.3 Amendments to DNSSEC-bis
The current DNSSEC-bis documents might need to be updated to indicate 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. 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 This is not a real change to the spec since implementers have been
warned not to synthesize with previously cached NSEC records. A warned not to synthesize with previously cached NSEC records. A
specific bit to identify the dynamic signature generating Key might specific bit to identify the dynamic signature generating key might
be useful as well, to prevent it from being used to fake positive be useful as well, to prevent it from being used to fake positive
data. data.
2.1.1.4 Cons 2.1.1.4 Cons
Unbalanced cost is a ground for DDoS. Though this protects against Unbalanced cost is a ground for DDoS. Though this protects against
enumeration, it is not really a path for versioning. enumeration, it is not really a path for versioning.
2.1.1.5 Pros 2.1.1.5 Pros
skipping to change at page 8, line 15 skipping to change at page 8, line 22
2.1.5.3 Amendments to DNSSEC-bis 2.1.5.3 Amendments to DNSSEC-bis
The current DNSSEC-bis documents need to be updated to indicate that The current DNSSEC-bis documents need to be updated to indicate that
the NXDOMAIN responses may be insecure. the NXDOMAIN responses may be insecure.
2.1.5.4 Cons 2.1.5.4 Cons
Strictly speaking this breaks the protocol and doesn't fully fulfill Strictly speaking this breaks the protocol and doesn't fully fulfill
the requirements for authenticated denial of existence. Security the requirements for authenticated denial of existence. Security
implications need to be carefully documented: search path problems implications need to be carefully documented: search path problems
(forged denial of existence may lead to wrong expansion of non-FQDNs, (forged denial of existence may lead to wrong expansion of non-FQDNs
cf. RFC 1535); replay attacks to deny existence of records [RFC1535]) and replay attacks to deny existence of records.
2.1.5.5 Pros 2.1.5.5 Pros
Hardly any amendments to DNSSEC-bis. Operational "trick" that is Hardly any amendments to DNSSEC-bis. Operational "trick" that is
available anyway. available anyway.
2.1.6 NSEC Optional via DNSSKEY Flag 2.1.6 NSEC Optional via DNSSKEY Flag
A new DNSKEY may be defined to declare NSEC optional per zone. A new DNSKEY may be defined to declare NSEC optional per zone.
2.1.6.1 Coexistence and Migration 2.1.6.1 Coexistence and Migration
Current resolvers/validators will not understand the Flag bit and Current resolvers/validators will not understand the Flag bit and
will have to treat negative responses as bogus. Otherwise, no will have to treat negative responses as bogus. Otherwise, no
migration path is needed since NSEC is simply turned off. migration path is needed since NSEC is simply turned off.
2.1.6.2 Limitations 2.1.6.2 Limitations
NSEC can only be made completely optional at the cost of being unable 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 to prove unsecure delegations (absence of a DS RR [RFC3658]). A next
approach would just disable authenticated denial for non-existence of to this approach would just disable authenticated denial for
nodes. non-existence of nodes.
2.1.6.3 Amendments to DNSSEC-bis 2.1.6.3 Amendments to DNSSEC-bis
New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to
be specified in the light of absence of authenticated denial. be specified in the light of absence of authenticated denial.
2.1.6.4 Cons 2.1.6.4 Cons
Doesn't fully meet requirements. Operational consequences to be Doesn't fully meet requirements. Operational consequences to be
studied. studied.
2.1.6.5 Pros 2.1.6.5 Pros
Official version of the "trick" presented in (8). Operational Official version of the "trick" presented in (8). Operational
problems can be addressed during future work on validators. problems can be addressed during future work on validators.
2.2 Mechanisms not Updating DNSSEC-bis 2.1.7 New Answer Pseudo RR Type
A new pseudo RR type may be defined that will be dynamically created
(and signed) by the responding authoritative server. The RR in the
response will cover the QNAME, QCLASS and QTYPE and will authenticate
both denial of existence of name (NXDOMAIN) or RRset.
2.1.7.1 Coexistence and Migration
Current resolvers/validators will not understand the pseudo RR and
will thus not be able to process negative responses so testified. A
signaling or solicitation method would have to be specified.
2.1.7.2 Limitations
This method can only be used with online keys and online signing
capacity.
2.1.7.3 Amendments to DNSSEC-bis
Signaling method needs to be defined.
2.1.7.4 Cons
Keys have to be held and processed online with all security
implications. An additional flag for those keys identifying them as
online or negative answer only keys should be considered.
2.1.7.5 Pros
Expands DNSSEC authentication to the RCODE.
2.1.8 SIG(0) Based Authenticated Denial
2.1.8.1 Coexistence and Migration
2.1.8.2 Limitations
2.1.8.3 Amendments to DNSSEC-bis
2.1.8.4 Cons
2.1.8.5 Pros
2.2 Mechanisms Without Need of Updating DNSSEC-bis
2.2.1 Partial Type-code and Signal Rollover 2.2.1 Partial Type-code and Signal Rollover
Carefully crafted type code/signal rollover to define a new Carefully crafted type code/signal rollover to define a new
authenticated denial space that extends/replaces DNSSEC-bis authenticated denial space that extends/replaces DNSSEC-bis
authenticated denial space. This particular path is illuminated by authenticated denial space. This particular path is illuminated by
Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com> Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com>
posted to <namedroppers@ops.ietf.org> 2004-06-02. posted to <namedroppers@ops.ietf.org> 2004-06-02.
2.2.1.1 Coexistence and Migration 2.2.1.1 Coexistence and Migration
skipping to change at page 11, line 35 skipping to change at page 12, line 47
The algorithm field was not designed for this purpose. This is a The algorithm field was not designed for this purpose. This is a
straightforward hack. straightforward hack.
2.2.3.5 Pros 2.2.3.5 Pros
No amendments/changes to current DNSSEC-bis docset needed. No amendments/changes to current DNSSEC-bis docset needed.
3. Recommendation 3. Recommendation
The authors recommend that the working group commits to and starts The authors recommend that the working group commits to and starts
work on a partial TCR, allowing gracefull transition towards a future work on a partial TCR, allowing graceful transition towards a future
version of NSEC. Meanwhile, to accomodate the need for an version of NSEC. Meanwhile, to accomodate the need for an
immediately, temporary, solution against zone-traversal, we recommend immediately, temporary, solution against zone-traversal, we recommend
On-Demand NSEC synthesis. On-Demand NSEC synthesis.
This approach does not require any mandatory changes to DNSSEC-bis, This approach does not require any mandatory changes to DNSSEC-bis,
does not violate the protocol and fulfills the requirements. As a does not violate the protocol and fulfills the requirements. As a
side effect, it moves the cost of implementation and deployment to side effect, it moves the cost of implementation and deployment to
the users (zone owners) of this mechanism. the users (zone owners) of this mechanism.
4. Acknowledgements
The authors would like to thank Sam Weiler and Mark Andrews for their
input and constructive comments.
5. References
5.1 Normative References
[I-D.ietf-dnsext-dnssec-intro]
Arends, R., Austein, R., Massey, D., Larson, M. and S.
Rose, "DNS Security Introduction and Requirements",
Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October
2004.
[I-D.ietf-dnsext-dnssec-protocol]
Arends, R., "Protocol Modifications for the DNS Security
Extensions",
Internet-Draft draft-ietf-dnsext-dnssec-protocol-09,
October 2004.
[I-D.ietf-dnsext-dnssec-records]
Arends, R., "Resource Records for the DNS Security
Extensions",
Internet-Draft draft-ietf-dnsext-dnssec-records-11,
October 2004.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000.
5.2 Informative References
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction
With Widely Deployed DNS Software", RFC 1535, October
1993.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
(RR)", RFC 3658, December 2003.
Authors' Addresses Authors' Addresses
Roy Arends Roy Arends
Telematica Instituut Telematica Instituut
Drienerlolaan 5 Brouwerijstraat 1
Enschede 7522 NB Enschede 7523 XC
Netherlands The Netherlands
Phone: +31 534850485 Phone: +31 534850485
EMail: roy.arends@telin.nl Email: roy.arends@telin.nl
Peter Koch Peter Koch
Universitaet Bielefeld DENIC eG
Bielefeld 33594 Wiesenh"uttenplatz 26
Frankfurt 60329
Germany Germany
Phone: +49 521 106 2902 Phone: +49 69 27235 0
EMail: pk@TechFak.Uni-Bielefeld.DE Email: pk@DENIC.DE
Jakob Schlyter Jakob Schlyter
NIC-SE NIC-SE
Box 5774 Box 5774
Stockholm SE-114 87 Stockholm SE-114 87
Sweden Sweden
EMail: jakob@nic.se Email: jakob@nic.se
URI: http://www.nic.se/ URI: http://www.nic.se/
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
skipping to change at page 13, line 41 skipping to change at page 15, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 26 change blocks. 
42 lines changed or deleted 154 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/