draft-ietf-dnsext-dnssec-trans-04.txt   draft-ietf-dnsext-dnssec-trans-05.txt 
DNS Extensions Working Group R. Arends DNS Extensions Working Group R. Arends
Internet-Draft Nominet UK Internet-Draft Nominet
Expires: December 28, 2006 P. Koch Intended status: Informational P. Koch
DENIC eG Expires: January 10, 2008 DENIC eG
J. Schlyter J. Schlyter
Kirei AB Kirei AB
June 26, 2006 July 9, 2007
Evaluating DNSSEC Transition Mechanisms Evaluating DNSSEC Transition Mechanisms
draft-ietf-dnsext-dnssec-trans-04.txt draft-ietf-dnsext-dnssec-trans-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 December 28, 2006. This Internet-Draft will expire on January 10, 2008.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
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. It is a snapshot of the DNSEXT working group discussion way forward. It is a snapshot of the DNSEXT working group discussion
of June 2004. of June 2004.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3 2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3
2.1. Mechanisms With Need of 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 . . . . . . . 5 2.1.2. Add Versioning/Subtyping to Current NSEC . . . . . . . 5
2.1.3. Type Bit Map NSEC Indicator . . . . . . . . . . . . . 6 2.1.3. Type Bit Map NSEC Indicator . . . . . . . . . . . . . 6
2.1.4. New Apex Type . . . . . . . . . . . . . . . . . . . . 7 2.1.4. New Apex Type . . . . . . . . . . . . . . . . . . . . 7
2.1.5. NSEC White Lies . . . . . . . . . . . . . . . . . . . 7 2.1.5. NSEC White Lies . . . . . . . . . . . . . . . . . . . 8
2.1.6. NSEC Optional via DNSKEY Flag . . . . . . . . . . . . 8 2.1.6. NSEC Optional via DNSKEY Flag . . . . . . . . . . . . 9
2.1.7. New Answer Pseudo RR Type . . . . . . . . . . . . . . 9 2.1.7. New Answer Pseudo RR Type . . . . . . . . . . . . . . 9
2.2. Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10 2.2. Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10
2.2.1. Partial Type-code and Signal Rollover . . . . . . . . 10 2.2.1. Partial Type-code and Signal Rollover . . . . . . . . 10
2.2.2. A Complete Type-code and Signal Rollover . . . . . . . 10 2.2.2. A Complete Type-code and Signal Rollover . . . . . . . 11
2.2.3. Unknown (New) Algorithm in DS, DNSKEY, and RRSIG . . . 11 2.2.3. Unknown (New) Algorithm in DS, DNSKEY, and RRSIG . . . 12
2.2.4. Unknown (New) Hash Algorithm in DS . . . . . . . . . . 12 2.2.4. Unknown (New) Hash Algorithm in DS . . . . . . . . . . 13
3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 13 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
This report shall document the process of dealing with the NSEC zone This report shall document the process of dealing with the NSEC zone
walking problem late in the Last Call for [RFC4033], [RFC4034], and walking problem late in the Last Call for [RFC4033], [RFC4034], and
[RFC4035] (further referred to as DNSSEC-bis). It preserves some of [RFC4035] (further referred to as DNSSEC-bis, with the obsoleted
the discussion that took place in the DNSEXT WG during the first half [RFC2535] representing DNSSEC). It preserves some of the discussion
of June 2004 as well as some additional ideas that came up as well as some additional ideas that came up subsequently.
subsequently.
This is an edited excerpt of the chairs' mail to the WG: 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 DNSSEC-bis. The chairs allow the working group a little over a
week (up to June 12, 2004) to come to consensus on a possible week (up to June 12, 2004) to come to consensus on a possible
modification to the document to enable gentle rollover. If that modification to the document to enable gentle rollover. If that
consensus cannot be reached the DNSSEC-bis documents will go out consensus cannot be reached the DNSSEC-bis documents will go out
skipping to change at page 3, line 41 skipping to change at page 3, line 40
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 of 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 implementation
deployment, including those which seem to be solely operational in and/or deployment, including those which seem to be solely
nature. operational in nature.
2. Transition Mechanisms 2. Transition Mechanisms
In the light of recent discussions and past proposals, we have found In the light of earlier discussions and past proposals, we have found
several ways to allow for transition to future expansion of several ways to allow for transition to future expansion of
authenticated denial. We tried to illuminate the paths and pitfalls authenticated denial. We tried to illuminate the paths and pitfalls
in these ways forward. Some proposals lead to a versioning of in these ways forward. Some proposals lead to a versioning of
DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other DNSSEC, where DNSSEC-bis may co-exist with a future DNSSEC-ter, other
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.
skipping to change at page 4, line 32 skipping to change at page 4, line 32
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
presumption of online signing. presumption of online signing.
2.1.1.1. Coexistence and Migration 2.1.1.1. Coexistence and Migration
There is no change in interpretation other then that the next owner There is no change in interpretation other than that the next owner
name might or might not exist. name might or might not exist.
2.1.1.2. Limitations 2.1.1.2. Limitations
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 negative responses with previously cached
specific bit to identify the dynamic signature generating key might NSEC records. A specific bit to identify the dynamic signature
be useful as well, to prevent it from being used to fake positive generating key might be useful as well, to prevent it from being used
data. to fake positive data, i.e., to limit the damage of a compromise of
the online key.
2.1.1.4. Cons 2.1.1.4. Cons
Unbalanced cost may be abused for Denial of Service (DoS) attacks on Unbalanced cost may be abused for Denial of Service (DoS) attacks on
the synthesizing name servers. While dynamic synthesis protects the synthesizing name servers. Also, this method requires all
against enumeration, it is not really a path for versioning. authoritative servers to have access to a private key. While dynamic
synthesis protects against enumeration, it is not really a path for
versioning.
2.1.1.5. Pros 2.1.1.5. Pros
Hardly any amendments to DNSSEC-bis. Only a minimal amendment to DNSSEC-bis is needed to allow "dangling"
pointers in an NSEC RR. However, implementations are not allowed to
exploit the additional knowledge that NSEC RRs provide anyway, so
this amendment is more formal in nature than actually having an
influence on complying implementations.
2.1.2. Add Versioning/Subtyping to Current NSEC 2.1.2. Add Versioning/Subtyping to Current NSEC
This proposal introduces versioning for the NSEC RR type (a.k.a. This proposal introduces versioning for the NSEC RR type (a.k.a.
subtyping) by adding a (one octet) version field to the NSEC RDATA. subtyping) by adding a (one octet) version field to the NSEC RDATA.
Version number 0 is assigned to the current (DNSSEC-bis) meaning, Version number 0 is assigned to the current (DNSSEC-bis) meaning,
making this an 'Must Be Zero' (MBZ) for the to be published docset. making this a 'Must Be Zero' (MBZ) for the to-be-published document
set.
2.1.2.1. Coexistence and Migration 2.1.2.1. Coexistence and Migration
Since the versioning is done inside the NSEC RR, different versions Since the versioning is done inside the NSEC RR, different versions
may coexist. However, depending on future methods, that may or may may coexist in a zone. However, depending on future methods, that
not be useful inside a single zone. Resolvers cannot ask for may or may not be useful. Resolvers cannot ask for specific NSEC
specific NSEC versions but may be able to indicate version support by versions but may be able to indicate version support by means of a
means of a to be defined EDNS option bit. to-be-defined EDNS option bit.
2.1.2.2. Limitations 2.1.2.2. Limitations
There are no technical limitations, though it will cause delay to There are no technical limitations, though introducing this method
allow testing of the (currently unknown) new NSEC interpretation. 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 Since the versioning and signaling is done inside the NSEC RR, future
methods will likely be restricted to a single RR type authenticated methods will likely be restricted to a single RR type for
denial (as opposed to e.g. NSEC-alt, which currently proposes three authenticated denial (as opposed to, e.g., NSEC-alt, which currently
RR types). proposes three RR types).
2.1.2.3. Amendments to DNSSEC-bis 2.1.2.3. Amendments to DNSSEC-bis
Full Update of the current DNSSEC-bis documents to provide for new Versioning or subtyping would require a full update of the current
fields in NSEC, while specifying behavior in case of unknown field DNSSEC-bis documents to provide for new fields in NSEC, including the
values. need to specify client behavior in response to unknown field values.
2.1.2.4. Cons 2.1.2.4. Cons
Though this is a clean and clear path without versioning DNSSEC, it Although this is a clear and clean path without versioning DNSSEC as
takes some time to design, gain consensus, update the current DNSSEC- a whole, it would take some time to design, gain consensus, update
bis document, test and implement a new authenticated denial record. the current DNSSEC-bis document set, test and implement a new DNS
record type for authenticated denial.
2.1.2.5. Pros 2.1.2.5. Pros
Does not introduce an iteration to DNSSEC while providing a clear and NSEC versioning does not introduce an iteration to DNSSEC while
clean migration strategy. providing a clear and clean migration strategy.
2.1.3. Type Bit Map NSEC Indicator 2.1.3. Type Bit Map NSEC Indicator
Bits in the type-bit-map are reused or allocated to signify the Bits in the type-bit-map are reused or allocated to signify the
interpretation of NSEC. interpretation of NSEC.
This proposal assumes that future extensions make use of the existing This proposal assumes that future extensions make use of the existing
NSEC RDATA syntax, while it may need to change the interpretation of NSEC RDATA syntax, while it may need to change the interpretation of
the RDATA or introduce an alternative denial mechanism, invoked by the RDATA or introduce an alternative denial mechanism, invoked by
the specific type-bit-map-bits. the specific type-bit-map-bits.
2.1.3.1. Coexistence and migration 2.1.3.1. Coexistence and migration
Old and new NSEC meaning could coexist, depending how the signaling Old and new NSEC meaning could coexist, depending how the signaling
would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR would be defined. The bits for NXT, KEY, SIG or other outdated RR
types are available as well as those covering meta/query types or types are available as well as those covering meta/query types or
types to be specifically allocated. types to be specifically allocated.
2.1.3.2. Limitations 2.1.3.2. Limitations
This mechanism uses an NSEC field that was not designed for that This mechanism uses an NSEC field that was not designed for that
purpose. Similar methods were discussed during the Opt-In discussion purpose. Similar methods were discussed during the Opt-In discussion
and the Silly-State discussion. and the Silly-State discussion.
2.1.3.3. Amendments to DNSSEC-bis 2.1.3.3. Amendments to DNSSEC-bis
The specific type-bit-map-bits must be allocated and they need to be 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) specified as 'Must Be Zero' (MBZ) when used for standard (DNSSEC-bis)
interpretation. Also, behaviour of the resolver and validator must interpretation. Also, behaviour of the resolver and validator must
be documented in case unknown values are encountered for the MBZ be specified in case unknown values are encountered for the MBZ
field. Currently the protocol document specifies that the validator field. Currently the protocol document specifies that the validator
MUST ignore the setting of the NSEC and the RRSIG bits, while other 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 bits are only used for the specific purpose of the type-bit-map
field.
2.1.3.4. Cons 2.1.3.4. Cons
The type-bit-map was not designed for this purpose. It is a Overloading the meaning of the type-bit-map is a straightforward
straightforward hack. Text in protocol section 5.4 was put in hack. The type-bit-map was not only not designed for this purpose,
specially to defend against this usage. but the text in section 5.4 of [RFC4035] was put in place to
explicitly prevent this usage.
2.1.3.5. Pros 2.1.3.5. Pros
No change needed to the on-the-wire protocol as specified in the No change is needed to the on-the-wire protocol as specified in the
current docset. current DNSSEC-bis document set.
2.1.4. New Apex Type 2.1.4. New Apex Type
This introduces a new Apex type (parallel to the zone's SOA) This introduces a new Apex type (parallel to the zone's SOA)
indicating the DNSSEC version (or authenticated denial) used in or indicating the DNSSEC version (or authenticated denial) used in or
for this zone. for this zone.
2.1.4.1. Coexistence and Migration 2.1.4.1. Coexistence and Migration
Depending on the design of this new RR type multiple denial Depending on the design of this new RR type multiple denial
skipping to change at page 8, line 14 skipping to change at page 8, line 28
2.1.5.1. Coexistence and Migration 2.1.5.1. Coexistence and Migration
The NSEC target can be specified per RR, so standard NSEC and 'white 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 lie' NSEC can coexist in a zone. There is no need for migration
because no versioning is introduced or intended. because no versioning is introduced or intended.
2.1.5.2. Limitations 2.1.5.2. Limitations
This proposal breaks the protocol and is applicable to certain types This proposal breaks the protocol and is applicable to certain types
of zones only (no wildcard, no deep names, delegation only). Most of of zones only (no wildcard, no multi-label names, delegation only).
the burden is put on the resolver side and operational consequences Most of the burden is put on the resolver side and operational
are yet to be studied. consequences are yet to be studied.
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 really satisfy
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
[RFC1535]) and replay attacks to deny existence of records. [RFC1535]) and replay attacks to deny existence of records. In
addition, this does not provide for a versioning or signalling
scheme.
2.1.5.5. Pros 2.1.5.5. Pros
Hardly any amendments to DNSSEC-bis. Operational "trick" that is Solves the enumeration problem without the need of additional RR
available anyway. types.
2.1.6. NSEC Optional via DNSKEY Flag 2.1.6. NSEC Optional via DNSKEY Flag
A new DNSKEY may be defined to declare NSEC optional per zone. A new DNSKEY Flag 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 a DS RR). A next to this to prove unsecure delegations (absence of a DS RR). An almost
approach would just disable authenticated denial for non-existence of identical approach would just disable authenticated denial for non-
nodes. 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 DNSSEC-bis less authenticated denial doesn't fully meet the
studied. requirements and breaks the DNSSEC protocol by not fully covering the
threat model. Existing implementations will be confused.
Operational consequences need to be studied.
2.1.6.5. Pros 2.1.6.5. Pros
Official version of the "trick" presented in Section 2.1.5. Positive responses can still be validated.
Operational problems can be addressed during future work on
validators.
2.1.7. New Answer Pseudo RR Type 2.1.7. New Answer Pseudo RR Type
A new pseudo RR type may be defined that will be dynamically created A new pseudo RR type may be defined that will be dynamically created
(and signed) by the responding authoritative server. The RR in the (and signed) by the responding authoritative server. The RR in the
response will cover the QNAME, QCLASS and QTYPE and will authenticate response will cover the QNAME, QCLASS and QTYPE and will authenticate
both denial of existence of name (NXDOMAIN) or RRset. both denial of existence of name (NXDOMAIN) or RRset.
2.1.7.1. Coexistence and Migration 2.1.7.1. Coexistence and Migration
skipping to change at page 9, line 47 skipping to change at page 10, line 18
capacity. capacity.
2.1.7.3. Amendments to DNSSEC-bis 2.1.7.3. Amendments to DNSSEC-bis
Signaling method needs to be defined. Signaling method needs to be defined.
2.1.7.4. Cons 2.1.7.4. Cons
Keys have to be held and processed online with all security Keys have to be held and processed online with all security
implications. An additional flag for those keys identifying them as implications. An additional flag for those keys identifying them as
online or negative answer only keys should be considered. online or negative answer only keys should be considered, for the
same reasons given in Section 2.1.1.
2.1.7.5. Pros 2.1.7.5. Pros
Expands DNSSEC authentication to the RCODE. Expands DNSSEC authentication to the RCODE.
2.2. Mechanisms Without Need of Updating DNSSEC-bis 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
skipping to change at page 10, line 46 skipping to change at page 11, line 19
special consideration. It might be easier to do a full TCR, since a special consideration. It might be easier to do a full TCR, since a
few of the types and signals need upgrading anyway. few of the types and signals need upgrading anyway.
2.2.1.5. Pros 2.2.1.5. Pros
Graceful adoption of future versions of NSEC, while there are no Graceful adoption of future versions of NSEC, while there are no
amendments to DNSSEC-bis. amendments to DNSSEC-bis.
2.2.2. A Complete Type-code and Signal Rollover 2.2.2. A Complete Type-code and Signal Rollover
A new DNSSEC space is defined which can exist independent of current A new DNSSEC type code space is defined which can exist independent
DNSSEC-bis space. of the current DNSSEC-bis type code space.
This proposal assumes that all current DNSSEC type-codes (RRSIG/ This proposal assumes that all current DNSSEC type-codes (RRSIG/
DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any future DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any future
versions of DNSSEC. Any future version of DNSSEC has its own types versions of DNSSEC. Any future version of DNSSEC has its own types
to allow for keys, signatures, authenticated denial, etcetera. to allow for keys, signatures, authenticated denial, etcetera.
2.2.2.1. Coexistence and Migration 2.2.2.1. Coexistence and Migration
Both spaces can co-exist. They can be made completely orthogonal. Both spaces can co-exist. They can be made completely orthogonal.
2.2.2.2. Limitations 2.2.2.2. Limitations
None. None.
2.2.2.3. Amendments to DNSSEC-bis 2.2.2.3. Amendments to DNSSEC-bis
None. None.
2.2.2.4. Cons 2.2.2.4. Cons
With this path we abandon the current DNSSEC-bis. Though it is easy With this path we abandon the current DNSSEC-bis. Although it is
to role specific well-known and well-tested parts into the re-write, easy to roll specific well-known and well-tested parts into the re-
once deployment has started this path is very expensive for write, once deployment has started, this path is very expensive for
implementers, registries, registrars and registrants as well as implementers, registries, registrars and registrants as well as
resolvers/users. A TCR is not to be expected to occur frequently, so resolver operators and users. A TCR is not to be expected to occur
while a next generation authenticated denial may be enabled by a TCR, frequently, so while a next generation authenticated denial may be
it is likely that that TCR will only be agreed upon if it serves a enabled by a TCR, it is likely that that TCR will only be agreed upon
whole basket of changes or additions. A quick introduction of if it serves a whole basket of changes or additions. A quick
NSEC-ng should not be expected from this path. introduction of NSEC-ng should not be expected from this path.
2.2.2.5. Pros 2.2.2.5. Pros
No amendments/changes to current DNSSEC-bis docset needed. It is No amendments/changes to current DNSSEC-bis docset needed. It is
always there as last resort. always there as last resort.
2.2.3. Unknown (New) Algorithm in DS, DNSKEY, and RRSIG 2.2.3. Unknown (New) Algorithm in DS, DNSKEY, and RRSIG
This proposal assumes that future extensions make use of the existing This proposal assumes that future extensions make use of the existing
NSEC RDATA syntax, while they may need to change the interpretation NSEC RDATA syntax, while they may need to change the interpretation
of the RDATA or introduce an alternative denial mechanism, invoked by of the RDATA or introduce an alternative denial mechanism, invoked by
the specific unknown (new) signing algorithm. The different the specific unknown (new) signing algorithm. The different
interpretation would be signaled by use of different signature interpretation would be signaled by use of different signature
algorithms in the DS RR at the parent. Consequently, the DNSKEY RR algorithms in the DS RR at the parent. Consequently, the DNSKEY RR
for the child zone's KSK would contain a matching algorithm field. for the child zone's KSK would contain a matching algorithm field.
2.2.3.1. Coexistence and migration 2.2.3.1. Coexistence and migration
Old and new NSEC RDATA interpretation or known and unknown signatures Old and new NSEC RDATA interpretation or known and unknown signatures
can NOT coexist in a zone since. While DS RRs with both new and well cannot coexist in a zone. While DS RRs with both new and well known
known algorithm designation could both exist at the parent, that algorithm designation could both exist at the parent, that would not
would not lead to an unambiguous interpretation of the NSEC RRs in lead to an unambiguous interpretation of the NSEC RRs in the zone.
the zone. RRSIG RRs need to cover complete RRSets, so it is not RRSIG RRs need to cover complete RRSets, so it is not possible to
possible to sign an 'old' NSEC RR with an RRSIG using an 'old' sign an 'old' NSEC RR with an RRSIG using an 'old' algorithm and
algorithm and then, at the same owner, sign another 'new' NSEC RR then, at the same owner, sign another 'new' NSEC RR with an RRSIG of
with an RRSIG of the 'new' algorithm type. the 'new' algorithm type. A similar approach was subsequently
standardized in [I-D.ietf-dnsext-dnssec-experiments].
2.2.3.2. Limitations 2.2.3.2. Limitations
Validating resolvers agnostic of the 'new' signing algorithm (which Validating resolvers agnostic of the 'new' signing algorithm (which
may be a well known algorithm, but might not be recognized due to the may be a well known algorithm, but might not be recognized due to the
new code) will treat the entire zone as insecure. new code) will treat the entire zone as insecure.
The algorithm version space is split for each future version of The algorithm number space might be split for each future version of
DNSSEC. Violation of the 'modular components' concept. We use the DNSSEC. Violation of the 'modular components' concept. We use the
'validator' to protect the 'resolver' from unknown interpretations. 'validator' to protect the 'resolver' from unknown interpretations.
2.2.3.3. Amendments to DNSSEC-bis 2.2.3.3. Amendments to DNSSEC-bis
None. None.
2.2.3.4. Cons 2.2.3.4. Cons
The algorithm field was not designed for this purpose. This is a The algorithm field was not designed for this purpose. This is a
skipping to change at page 12, line 47 skipping to change at page 13, line 27
Old and new NSEC RDATA interpretation or known and unknown signatures Old and new NSEC RDATA interpretation or known and unknown signatures
can NOT coexist in a zone. can NOT coexist in a zone.
2.2.4.2. Limitations 2.2.4.2. Limitations
Validating resolvers agnostic of the 'new' hashing algorithm (which Validating resolvers agnostic of the 'new' hashing algorithm (which
may be a well known algorithm, but might not be recognized due to the may be a well known algorithm, but might not be recognized due to the
new code) will treat the entire zone as insecure. new code) will treat the entire zone as insecure.
The digest type space is split for each future version of DNSSEC. The digest type space might be split for each future version of
Violation of the 'modular components' concept. We use the DNSSEC. Violation of the 'modular components' concept. We use the
'validator' to protect the 'resolver' from unknown interpretations. 'validator' to protect the 'resolver' from unknown interpretations.
2.2.4.3. Amendments to DNSSEC-bis 2.2.4.3. Amendments to DNSSEC-bis
None. None.
2.2.4.4. Cons 2.2.4.4. Cons
The digest type field was not designed for this purpose. This is a The digest type field was not designed for this purpose. This is a
straightforward hack. straightforward hack.
skipping to change at page 13, line 42 skipping to change at page 14, line 21
This document deals with transition mechanisms for new versions of This document deals with transition mechanisms for new versions of
the DNS Security Extensions. The particular considerations for the the DNS Security Extensions. The particular considerations for the
methods studied are listed in the respective sections, most methods studied are listed in the respective sections, most
importantly the requirement for keeping private keys online in importantly the requirement for keeping private keys online in
Section 2.1.1 and Section 2.1.7 and the full or partial abandoning of Section 2.1.1 and Section 2.1.7 and the full or partial abandoning of
authenticated denial in Section 2.1.5 and Section 2.1.6. authenticated denial in Section 2.1.5 and Section 2.1.6.
5. IANA Considerations 5. IANA Considerations
[[Note to the RFC Editor: This section may be removed prior to
publication.]]
This document does not create any new IANA registry nor does it ask This document does not create any new IANA registry nor does it ask
for any allocation from an existing IANA registry. for any allocation from an existing IANA registry.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank Sam Weiler and Mark Andrews for their The authors would like to thank Sam Weiler, Mark Andrews, and Stuart
input and constructive comments. Schechter for their input and constructive comments.
7. References 7. References
7.1. Normative References 7.1. Normative References
[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.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
7.2. Informative References 7.2. Informative References
[I-D.ietf-dnsext-dnssec-experiments]
Blacka, D., "DNSSEC Experiments",
draft-ietf-dnsext-dnssec-experiments-04 (work in
progress), March 2007.
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction [RFC1535] Gavron, E., "A Security Problem and Proposed Correction
With Widely Deployed DNS Software", RFC 1535, With Widely Deployed DNS Software", RFC 1535,
October 1993. October 1993.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
Authors' Addresses Authors' Addresses
Roy Arends Roy Arends
Nominet UK Nominet
Sandford Gate
Sandy Lane West
Oxford OX4 6LB
United Kingdom
Email: roy@nominet.org.uk Email: roy@nominet.org.uk
Peter Koch Peter Koch
DENIC eG DENIC eG
Wiesenhuettenplatz 26 Wiesenhuettenplatz 26
Frankfurt 60329 Frankfurt 60329
Germany Germany
Phone: +49 69 27235 0 Phone: +49 69 27235 0
skipping to change at page 16, line 5 skipping to change at page 16, line 5
Jakob Schlyter Jakob Schlyter
Kirei AB Kirei AB
P.O. Box 53204 P.O. Box 53204
Goteborg SE-400 16 Goteborg SE-400 16
Sweden Sweden
Email: jakob@kirei.se Email: jakob@kirei.se
URI: http://www.kirei.se/ URI: http://www.kirei.se/
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
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
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 16, line 29 skipping to change at page 16, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 52 change blocks. 
123 lines changed or deleted 144 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/