draft-ietf-dnsext-dnssec-trans-02.txt   draft-ietf-dnsext-dnssec-trans-03.txt 
DNS Extensions Working Group R. Arends DNS Extensions Working Group R. Arends
Internet-Draft Telematica Instituut Internet-Draft Telematica Instituut
Expires: August 25, 2005 P. Koch Expires: April 26, 2006 P. Koch
DENIC eG DENIC eG
J. Schlyter J. Schlyter
NIC-SE NIC-SE
February 21, 2005 October 23, 2005
Evaluating DNSSEC Transition Mechanisms Evaluating DNSSEC Transition Mechanisms
draft-ietf-dnsext-dnssec-trans-02.txt draft-ietf-dnsext-dnssec-trans-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
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-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 August 25, 2005. This Internet-Draft will expire on April 26, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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 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 . . . . . . . . . . . . . . . . . . . . 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.1.7 New Answer Pseudo RR Type . . . . . . . . . . . . . . 9 2.1.7. New Answer Pseudo RR Type . . . . . . . . . . . . . . 9
2.1.8 SIG(0) Based Authenticated Denial . . . . . . . . . . 9 2.2. Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 9
2.2 Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10 2.2.1. Partial Type-code and Signal Rollover . . . . . . . . 9
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 Algorithm in RRSIG . . . . . . . . . . . . . . 11 2.2.4. Unknown (New) Hash Algorithm in DS . . . . . . . . . . 12
3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1 Normative References . . . . . . . . . . . . . . . . . . . 13 5.1. Normative References . . . . . . . . . . . . . . . . . . . 13
5.2 Informative References . . . . . . . . . . . . . . . . . . 13 5.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
This report shall document the process of dealing with the NSEC This report shall document the process of dealing with the NSEC
walking problem late in the Last Call for walking problem late in the Last Call for [RFC4033], [RFC4034], and
[I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol, [RFC4035]. It preserves some of the discussion that took place in
I-D.ietf-dnsext-dnssec-records]. It preserves some of the discussion the DNSEXT WG during the first half of June 2004 as well as some
as well as some additional ideas that came up subsequently. additional ideas that came up 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 4, line 13 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 With Need of Updating DNSSEC-bis 2.1. Mechanisms With Need of Updating DNSSEC-bis
Mechanisms in this category demand updates to the DNSSEC-bis document Mechanisms in this category demand updates to the DNSSEC-bis document
set. 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
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 then 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 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
Hardly any amendments to DNSSEC-bis. Hardly any amendments to DNSSEC-bis.
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 an 'Must Be Zero' (MBZ) for the to be published docset.
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. However, depending on future methods, that may or may
not be useful inside a single zone. Resolvers cannot ask for not be useful inside a single zone. Resolvers cannot ask for
specific NSEC versions but may be able to indicate version support by specific NSEC versions but may be able to indicate version support by
means of a to be defined EDNS option bit. means of a 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 it will cause delay to
allow testing of the (currently unknown) new NSEC interpretation. 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 authenticated
denial (as opposed to e.g. NSEC-alt, which currently proposes three denial (as opposed to e.g. NSEC-alt, which currently proposes three
RR types). 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 Full Update of the current DNSSEC-bis documents to provide for new
fields in NSEC, while specifying behavior in case of unknown field fields in NSEC, while specifying behavior in case of unknown field
values. values.
2.1.2.4 Cons 2.1.2.4. Cons
Though this is a clean and clear path without versioning DNSSEC, it Though this is a clean and clear path without versioning DNSSEC, it
takes some time to design, gain consensus, update the current takes some time to design, gain consensus, update the current dnssec-
dnssec-bis document, test and implement a new authenticated denial bis document, test and implement a new authenticated denial record.
record.
2.1.2.5 Pros 2.1.2.5. Pros
Does not introduce an iteration to DNSSEC while providing a clear and Does not introduce an iteration to DNSSEC while providing a clear and
clean migration strategy. 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, NSEC, RRSIG 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 documented 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 The type-bit-map was not designed for this purpose. It is a
straightforward hack. Text in protocol section 5.4 was put in straightforward hack. Text in protocol section 5.4 was put in
specially to defend against this usage. specially to defend against 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 needed to the on-the-wire protocol as specified in the
current docset. current docset.
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
mechanisms may coexist in a zone. Old validators will not understand mechanisms may coexist in a zone. Old validators will not understand
and thus ignore the new type, so interpretation of the new NSEC and thus ignore the new type, so interpretation of the new NSEC
scheme may fail, negative responses may appear 'bogus'. scheme may fail, negative responses may appear 'bogus'.
2.1.4.2 Limitations 2.1.4.2. Limitations
A record of this kind is likely to carry additional A record of this kind is likely to carry additional feature/
feature/versioning indications unrelated to the current question of versioning indications unrelated to the current question of
authenticated denial. authenticated denial.
2.1.4.3 Amendments to DNSSEC-bis 2.1.4.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 absence of this type indicates dnssec-bis, and that the (mere) the absence of this type indicates dnssec-bis, and that the (mere)
presence of this type indicated unknown versions. presence of this type indicated unknown versions.
2.1.4.4 Cons 2.1.4.4. Cons
The only other 'zone' or 'apex' record is the SOA record. Though 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 this proposal is not new, it is yet unknown how it might fulfill
authenticated denial extensions. This new RR type would only provide authenticated denial extensions. This new RR type would only provide
for a generalized signaling mechanism, not the new authenticated for a generalized signaling mechanism, not the new authenticated
denial scheme. Since it is likely to be general in nature, due to denial scheme. Since it is likely to be general in nature, due to
this generality consensus is not to be reached soon. this generality consensus is not to be reached soon.
2.1.4.5 Pros 2.1.4.5. Pros
This approach would allow for a lot of other per zone information to This approach would allow for a lot of other per zone information to
be transported or signaled to both (slave) servers and resolvers. be transported or signaled to both (slave) servers and resolvers.
2.1.5 NSEC White Lies 2.1.5. NSEC White Lies
This proposal disables one part of NSEC (the pointer part) by means This proposal disables one part of NSEC (the pointer part) by means
of a special target (root, apex, owner, ...), leaving intact only the of a special target (root, apex, owner, ...), leaving intact only the
ability to authenticate denial of existence of RR sets, not denial of ability to authenticate denial of existence of RR sets, not denial of
existence of domain names (NXDOMAIN). It may be necessary to have existence of domain names (NXDOMAIN). It may be necessary to have
one working NSEC to prove the absence of a wildcard. one working NSEC to prove the absence of a wildcard.
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 deep names, delegation only). Most of
the burden is put on the resolver side and operational consequences the burden is put on the resolver side and operational consequences
are yet to be studied. 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 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
[RFC1535]) and 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 a DS RR [RFC3658]). A next to prove unsecure delegations (absence of a DS RR). A next to this
to this approach would just disable authenticated denial for approach would just disable authenticated denial for non-existence of
non-existence of nodes. 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.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
Current resolvers/validators will not understand the pseudo RR and Current resolvers/validators will not understand the pseudo RR and
will thus not be able to process negative responses so testified. A will thus not be able to process negative responses so testified. A
signaling or solicitation method would have to be specified. signaling or solicitation method would have to be specified.
2.1.7.2 Limitations 2.1.7.2. Limitations
This method can only be used with online keys and online signing This method can only be used with online keys and online signing
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.
2.1.7.5 Pros 2.1.7.5. Pros
Expands DNSSEC authentication to the RCODE. Expands DNSSEC authentication to the RCODE.
2.1.8 SIG(0) Based Authenticated Denial 2.2. Mechanisms Without Need of Updating DNSSEC-bis
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
To protect the current resolver for future versions, a new DNSSEC-OK 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 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 the future version. Also, a new DS type needs to be allocated to
allow differentiation between a current signed delegation and a allow differentiation between a current signed delegation and a
'future' signed delegation. Also, current NSEC needs to be rolled 'future' signed delegation. Also, current NSEC needs to be rolled
into a new authenticated denial type. into a new authenticated denial type.
2.2.1.2 Limitations 2.2.1.2. Limitations
None. None.
2.2.1.3 Amendments to DNSSEC-bis 2.2.1.3. Amendments to DNSSEC-bis
None. None.
2.2.1.4 Cons 2.2.1.4. Cons
It is cumbersome to carefully craft an TCR that 'just fits'. The It is cumbersome to carefully craft an TCR that 'just fits'. The
DNSSEC-bis protocol has many 'borderline' cases that needs special DNSSEC-bis protocol has many 'borderline' cases that needs special
consideration. It might be easier to do a full TCR, since a few of consideration. It might be easier to do a full TCR, since a few of
the types and signals need upgrading anyway. 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 space is defined which can exist independent of current
DNSSEC-bis space. DNSSEC-bis space.
This proposal assumes that all current DNSSEC type-codes This proposal assumes that all current DNSSEC type-codes (RRSIG/
(RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any future
future versions of DNSSEC. Any future version of DNSSEC has its own versions of DNSSEC. Any future version of DNSSEC has its own types
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. Though it is easy
to role specific well-known and well-tested parts into the re-write, to role specific well-known and well-tested parts into the re-write,
once deployment has started this path is very expensive for 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 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, 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 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 whole basket of changes or additions. A quick introduction of
NSEC-ng should not be expected from this path. 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 Algorithm in 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 it may need to change the interpretation of NSEC RDATA syntax, while they may need to change the interpretation
the RDATA or introduce an alternative denial mechanism, invoked by of the RDATA or introduce an alternative denial mechanism, invoked by
the specific unknown signing algorithm. The different interpretation the specific unknown (new) signing algorithm. The different
would be signaled by use of different signature algorithms in the interpretation would be signaled by use of different signature
RRSIG records covering the NSEC RRs. algorithms in the DS RR at the parent. Consequently, the DNSKEY RR
for the child zone's KSK would contain a matching algorithm field.
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 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 signatures cover complete (NSEC) can NOT coexist in a zone since. While DS RRs with both new and well
RRSets. known algorithm designation could both exist at the parent, that
would not lead to an unambiguous interpretation of the NSEC RRs in
the zone. RRSIG RRs need to cover complete RRSets, so it is not
possible to sign an 'old' NSEC RR with an RRSIG using an 'old'
algorithm and then, at the same owner, sign another 'new' NSEC RR
with an RRSIG of the 'new' algorithm type.
2.2.3.2 Limitations 2.2.3.2. Limitations
Validating resolvers agnostic of new interpretation will treat the Validating resolvers agnostic of the 'new' signing algorithm (which
NSEC RRset as "not signed". This affects wildcard and non-existence may be a well known algorithm, but might not be recognized due to the
proof, as well as proof for (un)secured delegations. Also, all new code) will treat the entire zone as insecure.
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 The algorithm version space is 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
straightforward hack. straightforward hack.
2.2.3.5 Pros 2.2.3.5. Pros
No amendments/changes to current DNSSEC-bis docset needed.
2.2.4. Unknown (New) Hash Algorithm in DS
Similar to the previous method this one uses the DS RR at the parent
to signal child zone properties. Here, the digest type field of the
DS RR would be used to signal presence of a different (than DNSSEC-
bis) authenticated denial scheme at the child.
2.2.4.1. Coexistence and migration
Old and new NSEC RDATA interpretation or known and unknown signatures
can NOT coexist in a zone.
2.2.4.2. Limitations
Validating resolvers agnostic of the 'new' hashing algorithm (which
may be a well known algorithm, but might not be recognized due to the
new code) will treat the entire zone as insecure.
The digest type 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.4.3. Amendments to DNSSEC-bis
None.
2.2.4.4. Cons
The digest type field was not designed for this purpose. This is a
straightforward hack.
2.2.4.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 graceful 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.
skipping to change at page 13, line 17 skipping to change at page 13, line 34
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 4. Acknowledgements
The authors would like to thank Sam Weiler and Mark Andrews for their The authors would like to thank Sam Weiler and Mark Andrews for their
input and constructive comments. input and constructive comments.
5. References 5. References
5.1 Normative 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", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
SIG(0)s)", RFC 2931, September 2000. Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
5.2 Informative References [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
5.2. Informative References
[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, October With Widely Deployed DNS Software", RFC 1535,
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.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. 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
Brouwerijstraat 1 Brouwerijstraat 1
Enschede 7523 XC Enschede 7523 XC
The Netherlands The Netherlands
Phone: +31 53 4850485 Phone: +31 53 4850485
Email: roy.arends@telin.nl Email: roy.arends@telin.nl
Peter Koch Peter Koch
DENIC eG DENIC eG
Wiesenh"uttenplatz 26 Wiesenhuettenplatz 26
Frankfurt 60329 Frankfurt 60329
Germany Germany
Phone: +49 69 27235 0 Phone: +49 69 27235 0
Email: pk@DENIC.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
 End of changes. 84 change blocks. 
165 lines changed or deleted 173 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/