draft-ietf-dnsext-signed-nonexistence-requirements-01.txt   draft-ietf-dnsext-signed-nonexistence-requirements-02.txt 
Network Working Group B. Laurie Network Working Group B. Laurie
Internet-Draft Nominet Internet-Draft Nominet
Expires: March 2, 2005 R. Loomis Expires: April 27, 2006 R. Loomis
SAIC SAIC
September 2004 October 24, 2005
Requirements related to DNSSEC Signed Proof of Non-Existence Requirements related to DNSSEC Signed Proof of Non-Existence
draft-ietf-dnsext-signed-nonexistence-requirements-01 draft-ietf-dnsext-signed-nonexistence-requirements-02
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 March 2, 2005. This Internet-Draft will expire on April 27, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
DNSSEC-bis uses the NSEC record to provide authenticated denial of DNSSEC-bis uses the NSEC record to provide authenticated denial of
existence of RRsets. NSEC also has the side-effect of permitting existence of RRsets. NSEC also has the side-effect of permitting
zone enumeration, even if zone transfers have been forbidden. zone enumeration, even if zone transfers have been forbidden.
Because some see this as a problem, this document has been assembled Because some see this as a problem, this document has been assembled
to detail the possible requirements for denial of existence A/K/A to detail the possible requirements for denial of existence A/K/A
signed proof of non-existence. signed proof of non-existence.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Non-purposes . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Zone Enumeration . . . . . . . . . . . . . . . . . . . . . . 3 3. Non-purposes . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Zone Enumeration II . . . . . . . . . . . . . . . . . . . . 4 4. Group 1 - Zone Enumeration and exposure . . . . . . . . . . . 4
5. Zone Enumeration III . . . . . . . . . . . . . . . . . . . . 4 5. Group 2 - Zone Size . . . . . . . . . . . . . . . . . . . . . 4
6. Exposure of Contents . . . . . . . . . . . . . . . . . . . . 4 6. Group 3 - Compatibility and Transition . . . . . . . . . . . . 5
7. Zone Size . . . . . . . . . . . . . . . . . . . . . . . . . 4 7. Group 4 - Empty Non-terminals . . . . . . . . . . . . . . . . 5
8. Single Method . . . . . . . . . . . . . . . . . . . . . . . 5 8. Group 5 - DNSSEC-Adoption and Zone-Growth Relationship . . . . 6
9. Empty Non-terminals . . . . . . . . . . . . . . . . . . . . 5 9. Group 6 - Non-overlap of denial records with possible zone
10. Prevention of Precomputed Dictionary Attacks . . . . . . . . 6 records . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
11. DNSSEC-Adoption and Zone-Growth Relationship . . . . . . . . 6 10. Group 7 - Exposure of Private Keys . . . . . . . . . . . . . . 7
12. Non-overlap of denial records with possible zone records . . 7 11. Group 8 - Minimisation of Zone Signing Cost . . . . . . . . . 8
13. Exposure of Private Keys . . . . . . . . . . . . . . . . . . 7 12. Group 9 - DoS prevention/symmetric cost . . . . . . . . . . . 8
14. Minimisation of Zone Signing Cost . . . . . . . . . . . . . 8 13. Group 10 - Acceptable Complexity . . . . . . . . . . . . . . . 8
15. Minimisation of Asymmetry . . . . . . . . . . . . . . . . . 8 14. Group 11 - Correctness . . . . . . . . . . . . . . . . . . . . 9
16. Minimisation of Client Complexity . . . . . . . . . . . . . 8 15. Group 12 - Purity of Namespace . . . . . . . . . . . . . . . . 9
17. Completeness . . . . . . . . . . . . . . . . . . . . . . . . 8 16. Group 13 - Replay Attacks . . . . . . . . . . . . . . . . . . 9
18. Purity of Namespace . . . . . . . . . . . . . . . . . . . . 8 17. Group 14 - Security during Zone Transition . . . . . . . . . . 10
19. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 8 18. Group 15a - Universal Signing . . . . . . . . . . . . . . . . 10
20. Compatibility with NSEC . . . . . . . . . . . . . . . . . . 8 19. Group 15b - Universal Signing . . . . . . . . . . . . . . . . 10
21. Compatibility with NSEC II . . . . . . . . . . . . . . . . . 9 20. Group 15c - Universal Signing . . . . . . . . . . . . . . . . 10
22. Compatibility with NSEC III . . . . . . . . . . . . . . . . 9 21. Group 16 - NSEC++ as seen by NSEC-only resolver . . . . . . . 11
23. Coexistence with NSEC . . . . . . . . . . . . . . . . . . . 9 22. Prioritization of Requirements . . . . . . . . . . . . . . . . 11
24. Coexistence with NSEC II . . . . . . . . . . . . . . . . . . 9 23. Requirements summary matrix . . . . . . . . . . . . . . . . . 11
25. Protocol Design . . . . . . . . . . . . . . . . . . . . . . 9 24. Non-requirements . . . . . . . . . . . . . . . . . . . . . . . 12
26. Process . . . . . . . . . . . . . . . . . . . . . . . . . . 9 25. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 26. Requirements notation . . . . . . . . . . . . . . . . . . . . 12
28. Requirements notation . . . . . . . . . . . . . . . . . . . 9 27. Security Considerations . . . . . . . . . . . . . . . . . . . 12
29. Security Considerations . . . . . . . . . . . . . . . . . . 10 28. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
30. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 28.1. Normative References . . . . . . . . . . . . . . . . . . 13
30.1 Normative References . . . . . . . . . . . . . . . . . . . 10 28.2. Informative References . . . . . . . . . . . . . . . . . 13
30.2 Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . 11
1. Introduction 1. Introduction
NSEC records allow trivial enumeration of zones - a situation that NSEC records allow trivial enumeration of zones - a situation that
has existed for several years but which has recently been raised as a has existed for several years but which has recently been raised as a
significant concern for DNSSECbis deployment in several zones. significant concern for DNSSECbis deployment in several zones.
Alternate proposals have been made that make zone enumeration more Alternate proposals have been made that make zone enumeration more
difficult, and some previous proposals to modify DNSSEC had related difficult, and some previous proposals to modify DNSSEC had related
requirements/desirements that are relevant to the discussion. In requirements/desirements that are relevant to the discussion. In
addition the original designs for NSEC/NXT records were based on addition the original designs for NSEC/NXT records were based on
working group discussions and the choices made were not always working group discussions and the choices made were not always
documented with context and requirements-- so some of those choices documented with context and requirements-- so some of those choices
may need to be restated as requirements. Overall, the working group may need to be restated as requirements. Overall, the working group
needs to better understand the requirements for denial of existence needs to better understand the requirements for denial of existence
(and certain other requirements related to DNSSECbis deployment) in (and certain other requirements related to DNSSECbis deployment) in
order to evaluate the proposals that may replace NSEC. order to evaluate the proposals that may replace NSEC. The -01
version of this document was presented at IETF61 on 10 November 2004
along with a re-categorization of the then-current list of potential
requirements. This version of the document formalizes that re-
categorization of the requirements, and is intended to serve as the
basis for further discussions and evaluation of potential solutions.
The final editing of the -02 document was principally conducted by
Rip Loomis as Ben Laurie is now actively involved in writing
documents and code to satisfy the requirements that this document
attempts to enumerate. As such, Rip is to blame for any newly
introduced errors or lacking detail (and probably most of any such
errors in previous versions as well).
2. Terminology
In the remainder of this document, "NSEC++" is used as shorthand for In the remainder of this document, "NSEC++" is used as shorthand for
"a denial of existence proof that will replace NSEC". "NSECbis" has "a denial of existence proof that will replace NSEC". "NSECbis" has
also been used as shorthand for this, but we avoid that usage since also been used as shorthand for this, but we avoid that usage since
NSECbis will not be part of DNSSECbis and therefore there might be NSECbis will not be part of DNSSECbis and therefore there might be
some confusion. some confusion. We also use the term "DNSSEC-TNG" A/K/A "DNSSECter".
This is meant to indicate the current DNSSECbis plus whatever changes
are required as part of NSEC++. We expect that DNSSECter will likely
still include the current NSEC record as well.
2. Non-purposes 3. Non-purposes
This document does not currently document the reasons why zone This document does not currently document the reasons why zone
enumeration might be "bad" from a privacy, security, business, or enumeration might be "bad" from a privacy, security, business, or
other perspective--except insofar as those reasons result in other perspective--except insofar as those reasons result in
requirements. Once the list of requirements is complete and vaguely requirements. Once the list of requirements is complete and vaguely
coherent, the trade-offs (reducing zone enumeration will have X cost, coherent, the trade-offs (reducing zone enumeration will have X cost,
while providing Y benefit) may be revisited. The editors of this while providing Y benefit) may be revisited. The editors of this
compendium received inputs on the potential reasons why zone compendium received inputs on the potential reasons why zone
enumeration is bad (and there was significant discussion on the enumeration is bad (and there was significant discussion on the
DNSEXT WG mailing list) but that information fell outside the scope DNSEXT WG mailing list) but that information fell outside the scope
of this document. of this document.
Note also that this document does not assume that NSEC *must* be Note also that this document does not assume that NSEC *must* be
replaced with NSEC++, if the requirements can be met through other replaced with NSEC++, if the requirements can be met through other
methods (e.g., "white lies" with the current NSEC). As is stated methods (e.g., "white lies" with the current NSEC). As is stated
above, this document is focused on requirements collection and above, this document is focused on requirements collection and
(ideally) prioritization rather than on the actual implementation. (ideally) prioritization rather than on the actual implementation.
3. Zone Enumeration 4. Group 1 - Zone Enumeration and exposure
Authenticated denial should not permit trivial zone enumeration.
Additional discussion: NSEC (and NXT before it) provide a linked
list that could be "walked" to trivially enumerate all the signed
records in a zone. This requirement is primarily (though not
exclusively) important for zones that either are delegation-only/
-mostly or do not have reverse lookup (PTR) records configured, since
enterprises that have PTR records for all A records have already
provided a similar capability to enumerate the contents of DNS zones.
Contributor: various
4. Zone Enumeration II
Zone enumeration should be at least as difficult as it would be to
effect a dictionary attack using simple DNS queries to do the same in
an unsecured zone.
(Editor comment: it is not clear how to measure difficulty in this
case. Some examples could be monetary cost, bandwidth, processing
power or some combination of these. It has also been suggested that
the requirement is that the graph of difficulty of enumeration vs.
the fraction of the zone enumerated should be approximately the same
shape in the two cases)
Contributor: Nominet
5. Zone Enumeration III
Enumeration of a zone with random contents should computationally
infeasible.
Editor comment: this is proposed as a way of evaluating the Comprised of previous requirements numbered as 3, 4, 5, 6, 10, and 26
effectiveness of a proposal rather than as a requirement anyone would
actually have in practice.
Contributor: Alex Bligh The editors suggest that these boil down to: "DNSSECter should not
make it easier to enumerate zones than it is with plain DNS."
6. Exposure of Contents We believe that this is a high-priority requirement.
NSEC++ should not expose any of the contents of the zone (apart from Threshold requirement: Enumeration is at least non-trivial (where
the NSEC++ records themselves, of course). current NSEC provides a linked list that is considered trivial to
walk).
Editor comment: this is a weaker requirement than prevention of A concrete test might be that a random zone is infeasible to fully
enumeration, but certainly any zone that satisfied this requirement enumerate--this also reflects the "goal requirement"
would also satisfy the trivial prevention of enumeration requirement.
Contributor: Ed Lewis Contributor: various
7. Zone Size 5. Group 2 - Zone Size
Requirement: NSEC++ should make it possible to take precautions Requirement: NSEC++ should make it possible to take precautions
against trivial zone size estimates. Since not all zone owners care against trivial zone size estimates. Since not all zone owners care
about others estimation of the size of a zone, it is not always about others estimation of the size of a zone, it is not always
necessary to prohibit trivial estimation of the size of the zone but necessary to prohibit trivial estimation of the size of the zone but
NSEC++ should allow such measures. NSEC++ should allow such measures.
We believe that this is a "nice to have" item and not a true
requirement, and recommend weighting it appropriately when
considering solutions.
Additional Discussion: Even with proposals based on obfuscating names Additional Discussion: Even with proposals based on obfuscating names
with hashes it is trivial to give very good estimates of the number with hashes it is trivial to give very good estimates of the number
of domains in a certain zone. Just send 10 random queries and look of domains in a certain zone. Just send 10 random queries and look
at the range between the two hash values returned in each NSEC++. As at the range between the two hash values returned in each NSEC++. As
hash output can be assumed to follow a rectangular random hash output can be assumed to follow a rectangular random
distribution, using the mean difference between the two values, you distribution, using the mean difference between the two values, you
can estimate the total number of records. It is probably sufficient can estimate the total number of records. It is probably sufficient
to look at even one NSEC++, since the two hash values should follow a to look at even one NSEC++, since the two hash values should follow a
(I believe) Poisson distribution. (I believe) Poisson distribution.
skipping to change at page 5, line 34 skipping to change at page 5, line 25
One simple attempt at solving this is to describe in the One simple attempt at solving this is to describe in the
specifications how zone signer tools can add a number of random specifications how zone signer tools can add a number of random
"junk" records. "junk" records.
Editor's comment: it is interesting that obfuscating names might Editor's comment: it is interesting that obfuscating names might
actually make it easier to estimate zone size. actually make it easier to estimate zone size.
Contributor: Simon Josefsson. Contributor: Simon Josefsson.
8. Single Method 6. Group 3 - Compatibility and Transition
Requirement: A single NSEC++ method must be able to carry both Comprised of requirements previously numbered as 8, 20, 21, 22, 23,
old-style denial (i.e. plain labels) and whatever the new style 24
looks like. Having two separate denial methods could result in
cornercases where one method can deny the other and vice versa.
Additional discussion: This requirement can help -bis folks to a Editor comments: The editors suggest that these boil down to,
smooth upgrade to -ter. First they'd change the method while the "Current deployment of DNSSECbis with NSEC, by those who care not
content is the same, then they can change content of the method. about zone enumeration, should not be affected by future NSEC++
deployment."
Contributor: Roy Arends. We believe that this is a high priority requirement.
9. Empty Non-terminals NOTE: Requirement 8 is no longer truly applicable, because it would
have mandated a change to the draft DNSSECbis documents that was not
made before they were submitted for IESG review.
Requirement: Empty-non-terminals (ENT) should remain empty. In Contributor: Various
other words, adding NSEC++ records to an existing DNS structure
should not cause the creation of NSEC++ records (or related records) 7. Group 4 - Empty Non-terminals
at points that are otherwise ENT.
Goal: Empty-non-terminals (ENT) should remain empty. In other words,
adding NSEC++ records to an existing DNS structure should not cause
the creation of NSEC++ records (or related records) at points that
are otherwise ENT.
Editor comments: We believe that this is a low-priority desire and
not a strict requirement, and we recommend that it be weighted
appropriately when comparing possible solutions.
Additional discussion: Currently NSEC complies with ENT requirement: Additional discussion: Currently NSEC complies with ENT requirement:
b.example.com NSEC a.c.example.com implies the existence of an ENT b.example.com NSEC a.c.example.com implies the existence of an ENT
with ownername c.example.com. NSEC2 breaks that requirement, since with ownername c.example.com. NSEC2 breaks that requirement, since
the ownername is entirely hashed causing the structure to disappear. the ownername is entirely hashed causing the structure to disappear.
This is why EXIST was introduced. But EXIST causes ENT to be This is why EXIST was introduced. But EXIST causes ENT to be non-
non-empty-terminals. Next to the dissappearance of ENT, it causes empty-terminals. Next to the dissappearance of ENT, it causes (some)
(some) overhead since an EXIST record needs a SIG, NSEC2 and overhead since an EXIST record needs a SIG, NSEC2 and SIG(NSEC2).
SIG(NSEC2). DNSNR honours this requirement by hashing individual DNSNR honours this requirement by hashing individual labels instead
labels instead of ownernames. However this causes very long labels. of ownernames. However this causes very long labels. Truncation is
Truncation is a measure against very long ownernames, but that is a measure against very long ownernames, but that is controversial.
controversial. There is a fair discussion of the validity of There is a fair discussion of the validity of truncation in the DNSNR
truncation in the DNSNR draft, but that hasn't got proper review yet. draft, but that hasn't got proper review yet.
NOTE: (2005-07-29) The discussion above may need some updates based
on NSEC3.
Contributor: Roy Arends. Contributor: Roy Arends.
(Editor comment: it is not clear to us that an EXIST record needs an (Editor comment: it is not clear to us that an EXIST record needs an
NSEC2 record, since it is a special purpose record only used for NSEC2 record, since it is a special purpose record only used for
denial of existence) denial of existence)
10. Prevention of Precomputed Dictionary Attacks 8. Group 5 - DNSSEC-Adoption and Zone-Growth Relationship
Requirement: NSEC++ needs to provide a method to reduce the
effectiveness of precomputed dictionary attacks.
Additional Discussion: Salt is a measure against dictionary attacks.
There are other possible measures (such as iterating hashes in
NSEC2). The salt needs to be communicated in every response, since
it is needed in every verification. Some have suggested to move the
salt to a special record instead of the denial record. I think this
is not wise. Response size has more priority over zone size. An
extra record causes a larger response than a larger existing record.
Contributor: Roy Arends.
(Editor comment: the current version of NSEC2 also has the salt in
every NSEC2 record)
11. DNSSEC-Adoption and Zone-Growth Relationship
Background: Currently with NSEC, when a delegation centric zone Background: Currently with NSEC, when a delegation centric zone
deploys DNSSEC, the zone-size multiplies by a non-trivial factor even deploys DNSSEC, the zone-size multiplies by a non-trivial factor even
when the DNSSEC-adoption rate of the subzones remains low--because when the DNSSEC-adoption rate of the subzones remains low--because
each delegation point creates at least one NSEC record and each delegation point creates at least one NSEC record and
corresponding signature in the parent even if the child is not corresponding signature in the parent even if the child is not
signed. signed.
Requirements: A delegation-only (or delegation-mostly) zone that is Goal/Requirements: A delegation-only (or delegation-mostly) zone that
signed but which has no signed child zones should initially need only is signed but which has no signed child zones should initially need
to add SIG(SOA), DNSKEY, and SIG(DNSKEY) at the apex, along with some only to add SIG(SOA), DNSKEY, and SIG(DNSKEY) at the apex, along with
minimal set of NSEC++ records to cover zone contents. Further, some minimal set of NSEC++ records to cover zone contents. Further,
during the transition of a delegation-only zone from 0% signed during the transition of a delegation-only zone from 0% signed
children to 100% signed children, the growth in the delegation-only children to 100% signed children, the growth in the delegation-only
zone should be roughly proportional to the percentage of signed child zone should be roughly proportional to the percentage of signed child
zones. zones.
Editor comments: We believe that this is a medium-priority goal or
desire and should be considered. Because of the similarity of this
item to the older "opt-in signed zones" proposal, we recognize that
consideration of this item may bog down the DNSEXT WG and that a
decision must be made by the WG chairs.
Additional Discussion: This is why DNSNR has the Authoritative Only Additional Discussion: This is why DNSNR has the Authoritative Only
bit. This is similar to opt-in for delegations only. This (bit) is bit. This is similar to opt-in for delegations only. This (bit) is
currently the only method to help delegation-centric zone cope with currently the only method to help delegation-centric zone cope with
zone-growth due to DNSSEC adoption. As an example, A delegation only zone-growth due to DNSSEC adoption. As an example, A delegation only
zone which deploys DNSSEC with the help of this bit, needs to add zone which deploys DNSSEC with the help of this bit, needs to add
SIG(SOA), DNSKEY, SIG(DNSKEY), DNSNR, SIG(DNSNR) at the apex. No SIG(SOA), DNSKEY, SIG(DNSKEY), DNSNR, SIG(DNSNR) at the apex. No
more than that. more than that.
NOTE: (2005-07-29) The discussion above may need some updates based
on NSEC3.
Contributor: Roy Arends. Contributor: Roy Arends.
12. Non-overlap of denial records with possible zone records 9. Group 6 - Non-overlap of denial records with possible zone records
Requirement: NSEC++ records should in some way be differentiated Goal: NSEC++ records should in some way be differentiated from
from regular zone records, so that there is no possibility that a regular zone records, so that there is no possibility that a record
record in the zone could be duplicated by a non-existence proof in the zone could be duplicated by a non-existence proof (NSEC++)
(NSEC++) record. record.
Editor comment: We are not sure that this is a valid concern much
less a requirement. Even if there is an apparent conflict or
overlap, the "conflicting" NSEC2 name _only_ appears in NSEC2
records, and the other name _never_ appears in NSEC2 records.
Protocols cannot protect against all possible silly or foolish
actions, and should a randomly chosen salt produce an NSEC2 record
that matches a zone entry (either current or future) then the
solution will be to pick a new salt and re-sign the zone.
Additional discussion: This requirement is derived from a discussion Additional discussion: This requirement is derived from a discussion
on the DNSEXT mailing list related to copyrights and domain names. on the DNSEXT mailing list related to copyrights and domain names.
As was outlined there, one solution is to put NSEC++ records in a As was outlined there, one solution would be to put NSEC++ records in
separate namespace, e.g.: $ORIGIN co.uk. a separate namespace, e.g.: $ORIGIN co.uk.
873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your 873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your
delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSEC++ 881345... delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSEC++ 881345... ;
; for amazon.co.uk. for amazon.co.uk. However, it is not obvious that this separate
namespace is useful.
Contributor: various Contributor: various
(Editor comment: One of us still does not see why a conflict 10. Group 7 - Exposure of Private Keys
matters. Even if there is an apparent conflict or overlap, the
"conflicting" NSEC2 name _only_ appears in NSEC2 records, and the
other name _never_ appears in NSEC2 records.)
13. Exposure of Private Keys
Private keys associated with the public keys in the DNS should be Private keys associated with the public keys in the DNS should be
exposed as little as possible. It is highly undesirable for private exposed as little as possible. It is highly undesirable for private
keys to be distributed to nameservers, or to otherwise be available keys to be distributed to nameservers, or to otherwise be available
in the run-time environment of nameservers. in the run-time environment of nameservers.
We believe that this is a medium priority desire. For some
organizations the use of online keys may be an acceptable trade-off
if it allows the prevention of zone enumeration. On the other hand,
there are some organizations which may be concerned about zone
enumeration and for whom online storage/availability of keys on the
authoritative servers may be unacceptable.
Contributors: Nominet, Olaf Kolkman, Ed Lewis Contributors: Nominet, Olaf Kolkman, Ed Lewis
14. Minimisation of Zone Signing Cost 11. Group 8 - Minimisation of Zone Signing Cost
The additional cost of creating an NSEC++ signed zone should not The additional cost of creating an NSEC++ signed zone should not
significantly exceed the cost of creating an ordinary signed zone. significantly exceed the cost of creating an ordinary signed zone.
Furthermore, DNSSEC++ should not make incremental signing of existing
zones any "harder" (in terms of computational or administrative
resources) than it currently is with DNSSECbis/NSEC.
We believe that this is a medium-priority desire.
Contributor: Nominet Contributor: Nominet
15. Minimisation of Asymmetry 12. Group 9 - DoS prevention/symmetric cost
Nameservers should have to do as little additional work as necessary. NSEC++ should not make Denial of Service (DoS) attacks significantly
More precisely, it is desirable for any increase in cost incurred by more effective than plain DNSSECbis. Any increase in real-time cost
the nameservers to be offset by a proportionate increase in cost to at the name server (to respond) should correspond to a proportional
DNS `clients', e.g. stub and/or `full-service' resolvers. increase in real-time cost to generate the original query.
Editor comment: We believe that this is a low-priority desire. In
general DNSSEC makes DoS attacks against both authoritative and
recursive DNS servers so much easier that the answer will be to
increase available server CPU resources. Further, we are not sure
that this a realistic requirement given the other requirements for
NSEC++. In the end, we recommend that this be considered along with
other factors when reviewing potential solutions.
Contributor: Nominet Contributor: Nominet
16. Minimisation of Client Complexity 13. Group 10 - Acceptable Complexity
Caching, wildcards, CNAMEs, DNAMEs should continue to work without Caching, wildcards, CNAMEs, and DNAMEs should continue to work
adding too much complexity at the client side. without significant increases in complexity at the client side--where
complexity specifically includes complexity of operational usage and
complexity of validator implementation.
We believe that this is a medium priority desire.
Contributor: Olaf Kolkman Contributor: Olaf Kolkman
17. Completeness 14. Group 11 - Correctness
A proof of nonexistence should be possible for all nonexistent data There should not be a proof of nonexistence possible for any valid
in the zone. data in the zone. NOTE: This has a much different meaning than the
way in which this requirement was stated as Completeness in the -01
version of this document, based on further discussions with the
original contributor.
This requirement now appears to conflict with Group 5 above and has
been given the same priority as Group 5 (previously requirement 11).
The WG will need to resolve the conflict and remove one of the two
goals/requirements from consideration.
Contributor: Olaf Kolkman Contributor: Olaf Kolkman
18. Purity of Namespace 15. Group 12 - Purity of Namespace
The name space should not be muddied with fake names or data sets. The name space should not be muddied with fake names or data sets.
Editor comment: After further discussion with the contributor, this
appears to be more of an awareness issue than a true requirement, and
one that may be possible to address on the implementation side. See
also Group 6, which appears to be based on similar concerns (although
the similarity was not identified during discussions at IETF 61).
Contributor: Ed Lewis Contributor: Ed Lewis
19. Replay Attacks 16. Group 13 - Replay Attacks
NSEC++ should not allow a replay to be used to deny existence of an Requirement: NSEC++ should not allow replay attacks that are any more
RR that actually exists. effective than those which currently exist in DNSSECbis.
Editor comment: This is a high-priority requirement. The requirement
was reworded based on further discussion with the original
contributor and other WG members. The basis for the rewording is
that DNSSECbis by design does not allow replay attacks that deny a
record which already exists. However, attacks against a record which
has been added will succeed (until the signature expires on the
relevant NSEC)
Contributor: Ed Lewis Contributor: Ed Lewis
20. Compatibility with NSEC 17. Group 14 - Security during Zone Transition
NSEC++ should not introduce changes incompatible with NSEC. Requirement: It should be possible to switch between NSEC and NSEC++
without any zone data appearing to be unsigned, insecure, or "partly
secure" during the transition, taking into account externally cached
data.
Contributor: Ed Lewis Additional discussion: We never want an end-user to see
"inconsistently signed" data. Both positive and negative answers
should still be able to be validated.
21. Compatibility with NSEC II Editor comment: This is a newly identified requirement. This is at
least highly desirable and perhaps a hard-and-fast requirement.
NSEC++ should differ from NSEC in a way that is transparent to the 18. Group 15a - Universal Signing
resolver or validator.
Contributor: Ed Lewis Editor comment: The 15 a/b/c nomenclature is used in this version for
consistency with the presentation made to DNSEXT by the editors
during IETF 61 in DC. This should probably be fixed in some way for
the next version of this document...hopefully in a way that minimizes
confusion.
22. Compatibility with NSEC III Requirement: "Every zone that can be signed with DNSSECbis can also
be signed with DNSSECter." (We believe that this is all zones, but
do not want to prove it nor raise the bar for DNSSECter.)
NSEC++ should differ from NSEC as little as possible whilst achieving Additional discussion: This is a newly-identified, hard-and-fast
other requirements. requirement.
Contributor: Alex Bligh 19. Group 15b - Universal Signing
23. Coexistence with NSEC Requirement: It should be possible to sign all zones with DNSSECter.
NSEC++ should be optional, allowing NSEC to be used instead. Additional discussion: Newly identified requirement. We rate this as
highly desirable.
Contributor: Ed Lewis, Alex Bligh 20. Group 15c - Universal Signing
24. Coexistence with NSEC II Requirement: If it is not possible to sign all zones with NSEC++,
then it should be clearly defined which zones cannot be signed.
NSEC++ should not impose extra work on those content with NSEC. This is a newly identified, hard-and-fast requirement.
Contributor: Ed Lewis 21. Group 16 - NSEC++ as seen by NSEC-only resolver
25. Protocol Design Requirement: An NSEC++ (only) zone, regardless of whether parent uses
NSEC or NSEC++, should appear as consistently unsigned when seen by
an NSEC-only resolver.
A good security protocol would allow signing the nonexistence of some Basis: We never want an end-user to see "inconsistently signed" data.
selected names without revealing anything about other names.
Contributor: Dan Bernstein This is a newly-identified requirement. This is at least highly
desirable and perhaps a hard-and-fast requirement.
26. Process 22. Prioritization of Requirements
Clearly not all of these requirements can be met. Therefore the next Clearly not all of these requirements can be met. Therefore the
phase of this document will be to either prioritise them or narrow editors have attempted to prioritize the requirements as they
them down to a non-contradictory set, which should then allow us to understand the relevant impacts and needs. The following lists give
judge proposals on the basis of their fit. details as to the prioritization. The order of listing within each
priority level is also intended to show which requirements should be
given higher priority if a "tie-breaker" is needed. Further, there
are likely some potential DNSSEC users who would assign different
priorities to specific requirement sets--these are meant to be an
overall list that best serves the wider community.
27. Acknowledgements High priority: Group 1 (Zone enumeration and exposure), group 3
(compatibility and transition), group 13 (replay), group 15a
(universal signing), and group 15c (universal signing).
28. Requirements notation Medium priority: Group 14 (security during transition), group 15b
(universal signing), Group 16 (NSEC-only resolver results), group 5
(adoption and zone growth), group 11 (completeness), group 7
(exposure of signing keys), group 10 (complexity), group 12 (DNS
"purity"), group 8 (zone signing cost)
Low priority: Group 9 (DoS prevention), group 2 (zone size), group 4
(Empty non-terminals), group 6 (non-overlap in namespace)
23. Requirements summary matrix
A HTML-ized matrix that summarizes the relationships between the
requirements (as they were identified in version -01 of this
document) is available at
http://www.cist-east.saic.com/~rip/requirements-matrix-2.htm Ideally
this HTML-ized matrix will be updated to match the slight terminology
changes in this version of the document, but even if it is updated it
will be difficult to include its presentation in any useful form in
an ASCII text I-D. It is possible that the next version of this
Draft will be complemented by a PDF version that includes the
(updated) matrix.
24. Non-requirements
Explicit non-requirement: Prevent enumeration of RR types for a given
name.
Even if it is notionally possible to provide this capability, we
expect a steep cost and little benefit.
Future provision of this capability is not prevented, if warranted.
25. Acknowledgements
The editors are indebted to all the individuals who provided feedback
on this and previous versions of this Internet Draft. In particular,
but in no particular order, Simon Josefsson, Roy Arends, Ed Lewis,
Olafur Gudmondsson, Olaf Kolkman, Alex Bligh, Bill Manning, Rob
Austein, and Rob Payne each asked specific questions or provided
specific content that helped the editors in refining this document.
26. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
29. Security Considerations 27. Security Considerations
There are currently no security considerations called out in this There are only very limited security considerations called out in
draft. There will be security considerations in the choice of which this draft, primarily related to questions of whether some of the
methods for avoiding zone enumeration might require a message to be
cryptographically signed "on the fly", which would imply that private
keys must in some way be accessible on authoritative nameservers.
There will be security considerations in the choice of which
requirements will be implemented, but there are no specific security requirements will be implemented, but there are no specific security
requirements during the requirements collection process. requirements during the requirements collection process.
30. References 28. References
30.1 Normative References 28.1. Normative References
[dnssecbis-protocol] [dnssecbis-protocol]
"DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some "DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some
Month 2004. Month 2004.
30.2 Informative References 28.2. Informative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and [RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998. Procedures", BCP 25, RFC 2418, September 1998.
Authors' Addresses Authors' Addresses
Ben Laurie Ben Laurie
Nominet Nominet
17 Perryn Road 17 Perryn Road
London W3 7LR London W3 7LR
England England
Phone: +44 (20) 8735 0686 Phone: +44 (20) 8735 0686
EMail: ben@algroup.co.uk Email: ben@algroup.co.uk
Rip Loomis Rip Loomis
Science Applications International Corporation Science Applications International Corporation
7125 Columbia Gateway Drive, Suite 300 7125 Columbia Gateway Drive, Suite 300
Columbia, MD 21046 Columbia, MD 21046
US US
EMail: gilbert.r.loomis@saic.com Email: gilbert.r.loomis@saic.com
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
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 11, 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. 79 change blocks. 
208 lines changed or deleted 314 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/