draft-ietf-dnsext-signed-nonexistence-requirements-02.txt   draft-ietf-dnsext-signed-nonexistence-requirements-03.txt 
Network Working Group B. Laurie Network Working Group B. Laurie
Internet-Draft Nominet Internet-Draft Nominet
Expires: April 27, 2006 R. Loomis Expires: December 18, 2006 R. Loomis
SAIC SAIC
October 24, 2005 June 16, 2006
Requirements related to DNSSEC Signed Proof of Non-Existence Requirements related to DNSSEC Signed Proof of Non-Existence
draft-ietf-dnsext-signed-nonexistence-requirements-02 draft-ietf-dnsext-signed-nonexistence-requirements-03
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 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 27, 2006. This Internet-Draft will expire on December 18, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
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.
skipping to change at page 2, line 21 skipping to change at page 2, line 21
5. Group 2 - Zone Size . . . . . . . . . . . . . . . . . . . . . 4 5. Group 2 - Zone Size . . . . . . . . . . . . . . . . . . . . . 4
6. Group 3 - Compatibility and Transition . . . . . . . . . . . . 5 6. Group 3 - Compatibility and Transition . . . . . . . . . . . . 5
7. Group 4 - Empty Non-terminals . . . . . . . . . . . . . . . . 5 7. Group 4 - Empty Non-terminals . . . . . . . . . . . . . . . . 5
8. Group 5 - DNSSEC-Adoption and Zone-Growth Relationship . . . . 6 8. Group 5 - DNSSEC-Adoption and Zone-Growth Relationship . . . . 6
9. Group 6 - Non-overlap of denial records with possible zone 9. Group 6 - Non-overlap of denial records with possible zone
records . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 records . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. Group 7 - Exposure of Private Keys . . . . . . . . . . . . . . 7 10. Group 7 - Exposure of Private Keys . . . . . . . . . . . . . . 7
11. Group 8 - Minimisation of Zone Signing Cost . . . . . . . . . 8 11. Group 8 - Minimisation of Zone Signing Cost . . . . . . . . . 8
12. Group 9 - DoS prevention/symmetric cost . . . . . . . . . . . 8 12. Group 9 - DoS prevention/symmetric cost . . . . . . . . . . . 8
13. Group 10 - Acceptable Complexity . . . . . . . . . . . . . . . 8 13. Group 10 - Acceptable Complexity . . . . . . . . . . . . . . . 8
14. Group 11 - Correctness . . . . . . . . . . . . . . . . . . . . 9 14. Group 11 - Completeness . . . . . . . . . . . . . . . . . . . 8
15. Group 12 - Purity of Namespace . . . . . . . . . . . . . . . . 9 15. Group 12 - Purity of Namespace . . . . . . . . . . . . . . . . 9
16. Group 13 - Replay Attacks . . . . . . . . . . . . . . . . . . 9 16. Group 13 - Replay Attacks . . . . . . . . . . . . . . . . . . 9
17. Group 14 - Security during Zone Transition . . . . . . . . . . 10 17. Group 14 - Security during Zone Transition . . . . . . . . . . 9
18. Group 15a - Universal Signing . . . . . . . . . . . . . . . . 10 18. Group 15a - Universal Signing . . . . . . . . . . . . . . . . 10
19. Group 15b - Universal Signing . . . . . . . . . . . . . . . . 10 19. Group 15b - Universal Signing . . . . . . . . . . . . . . . . 10
20. Group 15c - Universal Signing . . . . . . . . . . . . . . . . 10 20. Group 15c - Universal Signing . . . . . . . . . . . . . . . . 10
21. Group 16 - NSEC++ as seen by NSEC-only resolver . . . . . . . 11 21. Group 16 - NSEC++ as seen by NSEC-only resolver . . . . . . . 10
22. Prioritization of Requirements . . . . . . . . . . . . . . . . 11 22. Prioritization . . . . . . . . . . . . . . . . . . . . . . . . 11
23. Requirements summary matrix . . . . . . . . . . . . . . . . . 11 23. Non-requirements . . . . . . . . . . . . . . . . . . . . . . . 11
24. Non-requirements . . . . . . . . . . . . . . . . . . . . . . . 12 24. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
25. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 25. Requirements notation . . . . . . . . . . . . . . . . . . . . 11
26. Requirements notation . . . . . . . . . . . . . . . . . . . . 12 26. Security Considerations . . . . . . . . . . . . . . . . . . . 12
27. Security Considerations . . . . . . . . . . . . . . . . . . . 12 27. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
28. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 27.1. Normative References . . . . . . . . . . . . . . . . . . 12
28.1. Normative References . . . . . . . . . . . . . . . . . . 13 27.2. Informative References . . . . . . . . . . . . . . . . . 12
28.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
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
skipping to change at page 3, line 25 skipping to change at page 3, line 25
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. The -01 order to evaluate the proposals that may replace NSEC. The -01
version of this document was presented at IETF61 on 10 November 2004 version of this document was presented at IETF61 on 10 November 2004
along with a re-categorization of the then-current list of potential along with a re-categorization of the then-current list of potential
requirements. This version of the document formalizes that re- requirements. This version of the document formalizes that re-
categorization of the requirements, and is intended to serve as the categorization of the requirements, and is intended to serve as the
basis for further discussions and evaluation of potential solutions. 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 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. We also use the term "DNSSEC-TNG" A/K/A "DNSSECter". some confusion. We also use the term "DNSSEC-TNG" A/K/A "DNSSECter".
This is meant to indicate the current DNSSECbis plus whatever changes This is meant to indicate the current DNSSECbis plus whatever changes
are required as part of NSEC++. We expect that DNSSECter will likely are required as part of NSEC++. We expect that DNSSECter will likely
skipping to change at page 6, line 22 skipping to change at page 6, line 15
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 non- This is why EXIST was introduced. But EXIST causes ENT to be non-
empty-terminals. Next to the dissappearance of ENT, it causes (some) empty-terminals. Next to the dissappearance of ENT, it causes (some)
overhead since an EXIST record needs a SIG, NSEC2 and SIG(NSEC2). overhead since an EXIST record needs a SIG, NSEC2 and SIG(NSEC2).
DNSNR honours this requirement by hashing individual labels instead DNSNR honours this requirement by hashing individual labels instead
of ownernames. However this causes very long labels. Truncation is of ownernames. However this causes very long labels. Truncation is
a measure against very long ownernames, but that is controversial. a measure against very long ownernames, but that is controversial.
There is a fair discussion of the validity of truncation in the DNSNR There is a fair discussion of the validity of 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)
8. Group 5 - DNSSEC-Adoption and Zone-Growth Relationship 8. Group 5 - 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
skipping to change at page 7, line 15 skipping to change at page 7, line 6
decision must be made by the WG chairs. 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.
9. Group 6 - Non-overlap of denial records with possible zone records 9. Group 6 - Non-overlap of denial records with possible zone records
Goal: NSEC++ records should in some way be differentiated from Goal: NSEC++ records should in some way be differentiated from
regular zone records, so that there is no possibility that a record regular zone records, so that there is no possibility that a record
in the zone could be duplicated by a non-existence proof (NSEC++) in the zone could be duplicated by a non-existence proof (NSEC++)
record. record.
Editor comment: We are not sure that this is a valid concern much Editor comment: We are not sure that this is a valid concern much
skipping to change at page 9, line 12 skipping to change at page 8, line 45
Caching, wildcards, CNAMEs, and DNAMEs should continue to work Caching, wildcards, CNAMEs, and DNAMEs should continue to work
without significant increases in complexity at the client side--where without significant increases in complexity at the client side--where
complexity specifically includes complexity of operational usage and complexity specifically includes complexity of operational usage and
complexity of validator implementation. complexity of validator implementation.
We believe that this is a medium priority desire. We believe that this is a medium priority desire.
Contributor: Olaf Kolkman Contributor: Olaf Kolkman
14. Group 11 - Correctness 14. Group 11 - Completeness
There should not be a proof of nonexistence possible for any valid There should not be a proof of nonexistence possible for any valid
data in the zone. NOTE: This has a much different meaning than the 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 way in which this requirement was stated in the -01 version of this
version of this document, based on further discussions with the document, based on further discussions with the original contributor.
original contributor.
This requirement now appears to conflict with Group 5 above and has This requirement now appears to conflict with Group 5 above and has
been given the same priority as Group 5 (previously requirement 11). 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 The WG will need to resolve the conflict and remove one of the two
goals/requirements from consideration. goals/requirements from consideration.
Contributor: Olaf Kolkman Contributor: Olaf Kolkman
15. Group 12 - Purity of Namespace 15. Group 12 - Purity of Namespace
skipping to change at page 11, line 19 skipping to change at page 11, line 5
Requirement: An NSEC++ (only) zone, regardless of whether parent uses Requirement: An NSEC++ (only) zone, regardless of whether parent uses
NSEC or NSEC++, should appear as consistently unsigned when seen by NSEC or NSEC++, should appear as consistently unsigned when seen by
an NSEC-only resolver. an NSEC-only resolver.
Basis: We never want an end-user to see "inconsistently signed" data. Basis: We never want an end-user to see "inconsistently signed" data.
This is a newly-identified requirement. This is at least highly This is a newly-identified requirement. This is at least highly
desirable and perhaps a hard-and-fast requirement. desirable and perhaps a hard-and-fast requirement.
22. Prioritization of Requirements 22. Prioritization
Clearly not all of these requirements can be met. Therefore the Clearly not all of these requirements can be met. Therefore the
editors have attempted to prioritize the requirements as they editors have attempted to prioritize the requirements as they
understand the relevant impacts and needs. The following lists give understand the relevant impacts and needs. The following lists give
details as to the prioritization. The order of listing within each details as to the prioritization. The order of listing within each
priority level is also intended to show which requirements should be priority level is also intended to show which requirements should be
given higher priority if a "tie-breaker" is needed. Further, there given higher priority if a "tie-breaker" is needed. Further, there
are likely some potential DNSSEC users who would assign different are likely some potential DNSSEC users who would assign different
priorities to specific requirement sets--these are meant to be an priorities to specific requirement sets--these are meant to be an
overall list that best serves the wider community. overall list that best serves the wider community.
skipping to change at page 11, line 44 skipping to change at page 11, line 30
Medium priority: Group 14 (security during transition), group 15b Medium priority: Group 14 (security during transition), group 15b
(universal signing), Group 16 (NSEC-only resolver results), group 5 (universal signing), Group 16 (NSEC-only resolver results), group 5
(adoption and zone growth), group 11 (completeness), group 7 (adoption and zone growth), group 11 (completeness), group 7
(exposure of signing keys), group 10 (complexity), group 12 (DNS (exposure of signing keys), group 10 (complexity), group 12 (DNS
"purity"), group 8 (zone signing cost) "purity"), group 8 (zone signing cost)
Low priority: Group 9 (DoS prevention), group 2 (zone size), group 4 Low priority: Group 9 (DoS prevention), group 2 (zone size), group 4
(Empty non-terminals), group 6 (non-overlap in namespace) (Empty non-terminals), group 6 (non-overlap in namespace)
23. Requirements summary matrix 23. Non-requirements
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 Explicit non-requirement: Prevent enumeration of RR types for a given
name. name.
Even if it is notionally possible to provide this capability, we Even if it is notionally possible to provide this capability, we
expect a steep cost and little benefit. expect a steep cost and little benefit.
Future provision of this capability is not prevented, if warranted. Future provision of this capability is not prevented, if warranted.
25. Acknowledgements 24. 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 25. 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].
27. Security Considerations 26. Security Considerations
There are only very limited security considerations called out in There are only very limited security considerations called out in
this draft, primarily related to questions of whether some of the this draft, primarily related to questions of whether some of the
methods for avoiding zone enumeration might require a message to be methods for avoiding zone enumeration might require a message to be
cryptographically signed "on the fly", which would imply that private cryptographically signed "on the fly", which would imply that private
keys must in some way be accessible on authoritative nameservers. keys must in some way be accessible on authoritative nameservers.
There will be security considerations in the choice of which 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.
28. References 27. References
28.1. Normative References 27.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.
28.2. Informative References 27.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.
skipping to change at page 15, line 41 skipping to change at page 14, 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 (2005). This document is subject Copyright (C) The Internet Society (2006). 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. 22 change blocks. 
64 lines changed or deleted 30 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/