Network Working Group B. Laurie Internet-Draft Nominet Expires:
April 27,December 18, 2006 R. Loomis SAIC October 24, 2005June 16, 2006 Requirements related to DNSSEC Signed Proof of Non-Existence draft-ietf-dnsext-signed-nonexistence-requirements-02draft-ietf-dnsext-signed-nonexistence-requirements-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 27,December 18, 2006. Copyright Notice Copyright (C) The Internet Society (2005).(2006). Abstract DNSSEC-bis uses the NSEC record to provide authenticated denial of existence of RRsets. NSEC also has the side-effect of permitting zone enumeration, even if zone transfers have been forbidden. Because some see this as a problem, this document has been assembled to detail the possible requirements for denial of existence A/K/A signed proof of non-existence. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Non-purposes . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Group 1 - Zone Enumeration and exposure . . . . . . . . . . . 4 5. Group 2 - Zone Size . . . . . . . . . . . . . . . . . . . . . 4 6. Group 3 - Compatibility and Transition . . . . . . . . . . . . 5 7. Group 4 - Empty Non-terminals . . . . . . . . . . . . . . . . 5 8. Group 5 - DNSSEC-Adoption and Zone-Growth Relationship . . . . 6 9. Group 6 - Non-overlap of denial records with possible zone records . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. Group 7 - Exposure of Private Keys . . . . . . . . . . . . . . 7 11. Group 8 - Minimisation of Zone Signing Cost . . . . . . . . . 8 12. Group 9 - DoS prevention/symmetric cost . . . . . . . . . . . 8 13. Group 10 - Acceptable Complexity . . . . . . . . . . . . . . . 8 14. Group 11 - Correctness .Completeness . . . . . . . . . . . . . . . . . . . 98 15. Group 12 - Purity of Namespace . . . . . . . . . . . . . . . . 9 16. Group 13 - Replay Attacks . . . . . . . . . . . . . . . . . . 9 17. Group 14 - Security during Zone Transition . . . . . . . . . . 109 18. Group 15a - Universal Signing . . . . . . . . . . . . . . . . 10 19. Group 15b - Universal Signing . . . . . . . . . . . . . . . . 10 20. Group 15c - Universal Signing . . . . . . . . . . . . . . . . 10 21. Group 16 - NSEC++ as seen by NSEC-only resolver . . . . . . . 1110 22. Prioritization of Requirements . .. . . . . . . . . . . . . . 11 23. Requirements summary matrix . . . . . . .. . . . . . . . . . 11 24.23. Non-requirements . . . . . . . . . . . . . . . . . . . . . . . 12 25.11 24. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 26.11 25. Requirements notation . . . . . . . . . . . . . . . . . . . . 12 27.11 26. Security Considerations . . . . . . . . . . . . . . . . . . . 12 28.27. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 28.1.12 27.1. Normative References . . . . . . . . . . . . . . . . . . 13 28.2.12 27.2. Informative References . . . . . . . . . . . . . . . . . 1312 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 1413 Intellectual Property and Copyright Statements . . . . . . . . . . 1514 1. Introduction NSEC records allow trivial enumeration of zones - a situation that has existed for several years but which has recently been raised as a significant concern for DNSSECbis deployment in several zones. Alternate proposals have been made that make zone enumeration more difficult, and some previous proposals to modify DNSSEC had related requirements/desirements that are relevant to the discussion. In addition the original designs for NSEC/NXT records were based on working group discussions and the choices made were not always documented with context and requirements-- so some of those choices may need to be restated as requirements. Overall, the working group needs to better understand the requirements for denial of existence (and certain other requirements related to DNSSECbis deployment) in 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 "a denial of existence proof that will replace NSEC". "NSECbis" has 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 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. 3. Non-purposes This document does not currently document the reasons why zone enumeration might be "bad" from a privacy, security, business, or other perspective--except insofar as those reasons result in requirements. Once the list of requirements is complete and vaguely coherent, the trade-offs (reducing zone enumeration will have X cost, while providing Y benefit) may be revisited. The editors of this compendium received inputs on the potential reasons why zone enumeration is bad (and there was significant discussion on the DNSEXT WG mailing list) but that information fell outside the scope of this document. Note also that this document does not assume that NSEC *must* be replaced with NSEC++, if the requirements can be met through other methods (e.g., "white lies" with the current NSEC). As is stated above, this document is focused on requirements collection and (ideally) prioritization rather than on the actual implementation. 4. Group 1 - Zone Enumeration and exposure Comprised of previous requirements numbered as 3, 4, 5, 6, 10, and 26 The editors suggest that these boil down to: "DNSSECter should not make it easier to enumerate zones than it is with plain DNS." We believe that this is a high-priority requirement. Threshold requirement: Enumeration is at least non-trivial (where current NSEC provides a linked list that is considered trivial to walk). A concrete test might be that a random zone is infeasible to fully enumerate--this also reflects the "goal requirement" Contributor: various 5. Group 2 - Zone Size Requirement: NSEC++ should make it possible to take precautions against trivial zone size estimates. Since not all zone owners care 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 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 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 at the range between the two hash values returned in each NSEC++. As hash output can be assumed to follow a rectangular random distribution, using the mean difference between the two values, you 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 (I believe) Poisson distribution. The concern is motivated by some wording remembered from NSEC, which stated that NSEC MUST only be present for existing owner names in the zone, and MUST NOT be present for non-existing owner names. If similar wording were carried over to NSEC++, introducing bogus owner names in the hash chain (an otherwise simple solution to guard against trivial estimates of zone size) wouldn't be allowed. One simple attempt at solving this is to describe in the specifications how zone signer tools can add a number of random "junk" records. Editor's comment: it is interesting that obfuscating names might actually make it easier to estimate zone size. Contributor: Simon Josefsson. 6. Group 3 - Compatibility and Transition Comprised of requirements previously numbered as 8, 20, 21, 22, 23, 24 Editor comments: The editors suggest that these boil down to, "Current deployment of DNSSECbis with NSEC, by those who care not about zone enumeration, should not be affected by future NSEC++ deployment." We believe that this is a high priority requirement. 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. Contributor: Various 7. Group 4 - Empty Non-terminals 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: b.example.com NSEC a.c.example.com implies the existence of an ENT with ownername c.example.com. NSEC2 breaks that requirement, since the ownername is entirely hashed causing the structure to disappear. This is why EXIST was introduced. But EXIST causes ENT to be non- empty-terminals. Next to the dissappearance of ENT, it causes (some) overhead since an EXIST record needs a SIG, NSEC2 and SIG(NSEC2). DNSNR honours this requirement by hashing individual labels instead of ownernames. However this causes very long labels. Truncation is a measure against very long ownernames, but that is controversial. There is a fair discussion of the validity of truncation in the DNSNR 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. (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 denial of existence) 8. Group 5 - DNSSEC-Adoption and Zone-Growth Relationship Background: Currently with NSEC, when a delegation centric zone deploys DNSSEC, the zone-size multiplies by a non-trivial factor even when the DNSSEC-adoption rate of the subzones remains low--because each delegation point creates at least one NSEC record and corresponding signature in the parent even if the child is not signed. Goal/Requirements: A delegation-only (or delegation-mostly) zone that is signed but which has no signed child zones should initially need only to add SIG(SOA), DNSKEY, and SIG(DNSKEY) at the apex, along with some minimal set of NSEC++ records to cover zone contents. Further, during the transition of a delegation-only zone from 0% signed children to 100% signed children, the growth in the delegation-only zone should be roughly proportional to the percentage of signed child 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 bit. This is similar to opt-in for delegations only. This (bit) is currently the only method to help delegation-centric zone cope with 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 SIG(SOA), DNSKEY, SIG(DNSKEY), DNSNR, SIG(DNSNR) at the apex. No more than that. NOTE: (2005-07-29) The discussion above may need some updates based on NSEC3.Contributor: Roy Arends. 9. Group 6 - Non-overlap of denial records with possible zone records Goal: NSEC++ records should in some way be differentiated from regular zone records, so that there is no possibility that a record in the zone could be duplicated by a non-existence proof (NSEC++) 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 on the DNSEXT mailing list related to copyrights and domain names. As was outlined there, one solution would be to put NSEC++ records in a separate namespace, e.g.: $ORIGIN co.uk. 873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSEC++ 881345... ; for amazon.co.uk. However, it is not obvious that this separate namespace is useful. Contributor: various 10. Group 7 - Exposure of Private Keys Private keys associated with the public keys in the DNS should be exposed as little as possible. It is highly undesirable for private keys to be distributed to nameservers, or to otherwise be available 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 11. Group 8 - Minimisation of Zone Signing Cost The additional cost of creating an NSEC++ signed zone should not 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 12. Group 9 - DoS prevention/symmetric cost NSEC++ should not make Denial of Service (DoS) attacks significantly more effective than plain DNSSECbis. Any increase in real-time cost at the name server (to respond) should correspond to a proportional 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 13. Group 10 - Acceptable Complexity Caching, wildcards, CNAMEs, and DNAMEs should continue to work 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 14. Group 11 - CorrectnessCompleteness 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 way in which this requirement was stated as Completenessin 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 15. Group 12 - Purity of Namespace 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 16. Group 13 - Replay Attacks Requirement: NSEC++ should not allow replay attacks that are any more 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 17. Group 14 - Security during Zone Transition 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. 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. Editor comment: This is a newly identified requirement. This is at least highly desirable and perhaps a hard-and-fast requirement. 18. Group 15a - Universal Signing 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. 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.) Additional discussion: This is a newly-identified, hard-and-fast requirement. 19. Group 15b - Universal Signing Requirement: It should be possible to sign all zones with DNSSECter. Additional discussion: Newly identified requirement. We rate this as highly desirable. 20. Group 15c - Universal Signing Requirement: If it is not possible to sign all zones with NSEC++, then it should be clearly defined which zones cannot be signed. This is a newly identified, hard-and-fast requirement. 21. Group 16 - NSEC++ as seen by NSEC-only resolver 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. Basis: We never want an end-user to see "inconsistently signed" data. This is a newly-identified requirement. This is at least highly desirable and perhaps a hard-and-fast requirement. 22. Prioritization of RequirementsClearly not all of these requirements can be met. Therefore the editors have attempted to prioritize the requirements as they understand the relevant impacts and needs. The following lists give 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. 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). 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.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.25. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 27.26. Security Considerations There are only very limited security considerations called out in 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 during the requirements collection process. 28.27. References 18.104.22.168. Normative References [dnssecbis-protocol] "DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some Month 2004. 22.214.171.124. Informative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998. Authors' Addresses Ben Laurie Nominet 17 Perryn Road London W3 7LR England Phone: +44 (20) 8735 0686 Email: email@example.com Rip Loomis Science Applications International Corporation 7125 Columbia Gateway Drive, Suite 300 Columbia, MD 21046 US Email: firstname.lastname@example.org Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005).(2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.