From 85587a04e6514ec6976755d176bbfdcd1a6d917f Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 19 Jan 2009 05:12:06 +0000 Subject: [PATCH] new draft --- ...raft-ietf-dnsext-dnssec-bis-updates-01.txt | 616 ---------------- ...raft-ietf-dnsext-dnssec-bis-updates-08.txt | 672 ++++++++++++++++++ 2 files changed, 672 insertions(+), 616 deletions(-) delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-bis-updates-08.txt diff --git a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt deleted file mode 100644 index 3a800f9888..0000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt +++ /dev/null @@ -1,616 +0,0 @@ - - - -Network Working Group S. Weiler -Internet-Draft SPARTA, Inc -Updates: 4034, 4035 (if approved) May 23, 2005 -Expires: November 24, 2005 - - - Clarifications and Implementation Notes for DNSSECbis - draft-ietf-dnsext-dnssec-bis-updates-01 - -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 November 24, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This document is a collection of minor technical clarifications to - the DNSSECbis document set. It is meant to serve as a resource to - implementors as well as an interim repository of possible DNSSECbis - errata. - - - - - - - -Weiler Expires November 24, 2005 [Page 1] - -Internet-Draft DNSSECbis Implementation Notes May 2005 - - -Proposed additions in future versions - - An index sorted by the section of DNSSECbis being clarified. - - A list of proposed protocol changes being made in other documents, - such as NSEC3 and Epsilon. This document would not make those - changes, merely provide an index into the documents that are making - changes. - -Changes between -00 and -01 - - Document significantly restructured. - - Added section on QTYPE=ANY. - -Changes between personal submission and first WG draft - - Added Section 2.1 based on namedroppers discussions from March 9-10, - 2005. - - Added Section 3.4, Section 3.3, Section 4.3, and Section 2.2. - - Added the DNSSECbis RFC numbers. - - Figured out the confusion in Section 4.1. - - - - - - - - - - - - - - - - - - - - - - - - - - -Weiler Expires November 24, 2005 [Page 2] - -Internet-Draft DNSSECbis Implementation Notes May 2005 - - -Table of Contents - - 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4 - 1.1 Structure of this Document . . . . . . . . . . . . . . . . 4 - 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Significant Concerns . . . . . . . . . . . . . . . . . . . . . 4 - 2.1 Clarifications on Non-Existence Proofs . . . . . . . . . . 4 - 2.2 Empty Non-Terminal Proofs . . . . . . . . . . . . . . . . 5 - 2.3 Validating Responses to an ANY Query . . . . . . . . . . . 5 - 3. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5 - 3.1 Unknown DS Message Digest Algorithms . . . . . . . . . . . 5 - 3.2 Private Algorithms . . . . . . . . . . . . . . . . . . . . 6 - 3.3 Caution About Local Policy and Multiple RRSIGs . . . . . . 6 - 3.4 Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7 - 4. Minor Corrections and Clarifications . . . . . . . . . . . . . 7 - 4.1 Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 7 - 4.2 Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 7 - 4.3 Errors in Examples . . . . . . . . . . . . . . . . . . . . 8 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 7.1 Normative References . . . . . . . . . . . . . . . . . . . 8 - 7.2 Informative References . . . . . . . . . . . . . . . . . . 9 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 - A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 - Intellectual Property and Copyright Statements . . . . . . . . 11 - - - - - - - - - - - - - - - - - - - - - - - - - -Weiler Expires November 24, 2005 [Page 3] - -Internet-Draft DNSSECbis Implementation Notes May 2005 - - -1. Introduction and Terminology - - This document lists some minor clarifications and corrections to - DNSSECbis, as described in [1], [2], and [3]. - - It is intended to serve as a resource for implementors and as a - repository of items that need to be addressed when advancing the - DNSSECbis documents from Proposed Standard to Draft Standard. - - In this version (-01 of the WG document), feedback is particularly - solicited on the structure of the document and whether the text in - the recently added sections is correct and sufficient. - - Proposed substantive additions to this document should be sent to the - namedroppers mailing list as well as to the editor of this document. - The editor would greatly prefer text suitable for direct inclusion in - this document. - -1.1 Structure of this Document - - The clarifications to DNSSECbis are sorted according to the editor's - impression of their importance, starting with ones which could, if - ignored, lead to security and stability problems and progressing down - to clarifications that are likely to have little operational impact. - Mere typos and awkward phrasings are not addressed unless they could - lead to misinterpretation of the DNSSECbis documents. - -1.2 Terminology - - 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 RFC 2119 [4]. - -2. Significant Concerns - - This section provides clarifications that, if overlooked, could lead - to security issues or major interoperability problems. - -2.1 Clarifications on Non-Existence Proofs - - RFC4035 Section 5.4 slightly underspecifies the algorithm for - checking non-existence proofs. In particular, the algorithm there - might incorrectly allow the NSEC from the parent side of a zone cut - to prove the non-existence of either other RRs at that name in the - child zone or other names in the child zone. It might also allow a - NSEC at the same name as a DNAME to prove the non-existence of names - beneath that DNAME. - - - - -Weiler Expires November 24, 2005 [Page 4] - -Internet-Draft DNSSECbis Implementation Notes May 2005 - - - A parent-side delegation NSEC (one with the NS bit set, but no SOA - bit set, and with a singer field that's shorter than the owner name) - must not be used to assume non-existence of any RRs below that zone - cut (both RRs at that ownername and at ownernames with more leading - labels, no matter their content). Similarly, an NSEC with the DNAME - bit set must not be used to assume the non-existence of any - descendant of that NSEC's owner name. - -2.2 Empty Non-Terminal Proofs - - To be written, based on Roy Arends' May 11th message to namedroppers. - -2.3 Validating Responses to an ANY Query - - RFC4035 does not address now to validate responses when QTYPE=*. As - described in Section 6.2.2 of RFC1034, a proper response to QTYPE=* - may include a subset of the RRsets at a given name -- it is not - necessary to include all RRsets at the QNAME in the response. - - When validating a response to QTYPE=*, validate all received RRsets - that match QNAME and QCLASS. If any of those RRsets fail validation, - treat the answer as Bogus. If there are no RRsets matching QNAME and - QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as - clarified in this document). To be clear, a validator must not - insist on receiving all records at the QNAME in response to QTYPE=*. - -3. Interoperability Concerns - -3.1 Unknown DS Message Digest Algorithms - - Section 5.2 of RFC4035 includes rules for how to handle delegations - to zones that are signed with entirely unsupported algorithms, as - indicated by the algorithms shown in those zone's DS RRsets. It does - not explicitly address how to handle DS records that use unsupported - message digest algorithms. In brief, DS records using unknown or - unsupported message digest algorithms MUST be treated the same way as - DS records referring to DNSKEY RRs of unknown or unsupported - algorithms. - - The existing text says: - - If the validator does not support any of the algorithms listed - in an authenticated DS RRset, then the resolver has no supported - authentication path leading from the parent to the child. The - resolver should treat this case as it would the case of an - authenticated NSEC RRset proving that no DS RRset exists, as - described above. - - - - -Weiler Expires November 24, 2005 [Page 5] - -Internet-Draft DNSSECbis Implementation Notes May 2005 - - - To paraphrase the above, when determining the security status of a - zone, a validator discards (for this purpose only) any DS records - listing unknown or unsupported algorithms. If none are left, the - zone is treated as if it were unsigned. - - Modified to consider DS message digest algorithms, a validator also - discards any DS records using unknown or unsupported message digest - algorithms. - -3.2 Private Algorithms - - As discussed above, section 5.2 of RFC4035 requires that validators - make decisions about the security status of zones based on the public - key algorithms shown in the DS records for those zones. In the case - of private algorithms, as described in RFC4034 Appendix A.1.1, the - eight-bit algorithm field in the DS RR is not conclusive about what - algorithm(s) is actually in use. - - If no private algorithms appear in the DS set or if any supported - algorithm appears in the DS set, no special processing will be - needed. In the remaining cases, the security status of the zone - depends on whether or not the resolver supports any of the private - algorithms in use (provided that these DS records use supported hash - functions, as discussed in Section 3.1). In these cases, the - resolver MUST retrieve the corresponding DNSKEY for each private - algorithm DS record and examine the public key field to determine the - algorithm in use. The security-aware resolver MUST ensure that the - hash of the DNSKEY RR's owner name and RDATA matches the digest in - the DS RR. If they do not match, and no other DS establishes that - the zone is secure, the referral should be considered BAD data, as - discussed in RFC4035. - - This clarification facilitates the broader use of private algorithms, - as suggested by [5]. - -3.3 Caution About Local Policy and Multiple RRSIGs - - When multiple RRSIGs cover a given RRset, RFC4035 Section 5.3.3 - suggests that "the local resolver security policy determines whether - the resolver also has to test these RRSIG RRs and how to resolve - conflicts if these RRSIG RRs lead to differing results." In most - cases, a resolver would be well advised to accept any valid RRSIG as - sufficient. If the first RRSIG tested fails validation, a resolver - would be well advised to try others, giving a successful validation - result if any can be validated and giving a failure only if all - RRSIGs fail validation. - - If a resolver adopts a more restrictive policy, there's a danger that - - - -Weiler Expires November 24, 2005 [Page 6] - -Internet-Draft DNSSECbis Implementation Notes May 2005 - - - properly-signed data might unnecessarily fail validation, perhaps - because of cache timing issues. Furthermore, certain zone management - techniques, like the Double Signature Zone-signing Key Rollover - method described in section 4.2.1.2 of [6] might not work reliably. - -3.4 Key Tag Calculation - - RFC4034 Appendix B.1 incorrectly defines the Key Tag field - calculation for algorithm 1. It correctly says that the Key Tag is - the most significant 16 of the least significant 24 bits of the - public key modulus. However, RFC4034 then goes on to incorrectly say - that this is 4th to last and 3rd to last octets of the public key - modulus. It is, in fact, the 3rd to last and 2nd to last octets. - -4. Minor Corrections and Clarifications - -4.1 Finding Zone Cuts - - Appendix C.8 of RFC4035 discusses sending DS queries to the servers - for a parent zone. To do that, a resolver may first need to apply - special rules to discover what those servers are. - - As explained in Section 3.1.4.1 of RFC4035, security-aware name - servers need to apply special processing rules to handle the DS RR, - and in some situations the resolver may also need to apply special - rules to locate the name servers for the parent zone if the resolver - does not already have the parent's NS RRset. Section 4.2 of RFC4035 - specifies a mechanism for doing that. - -4.2 Clarifications on DNSKEY Usage - - Questions of the form "can I use a different DNSKEY for signing the - X" have occasionally arisen. - - The short answer is "yes, absolutely". You can even use a different - DNSKEY for each RRset in a zone, subject only to practical limits on - the size of the DNSKEY RRset. However, be aware that there is no way - to tell resolvers what a particularly DNSKEY is supposed to be used - for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to - authenticate any RRset in the zone. For example, if a weaker or less - trusted DNSKEY is being used to authenticate NSEC RRsets or all - dynamically updated records, that same DNSKEY can also be used to - sign any other RRsets from the zone. - - Furthermore, note that the SEP bit setting has no effect on how a - DNSKEY may be used -- the validation process is specifically - prohibited from using that bit by RFC4034 section 2.1.2. It possible - to use a DNSKEY without the SEP bit set as the sole secure entry - - - -Weiler Expires November 24, 2005 [Page 7] - -Internet-Draft DNSSECbis Implementation Notes May 2005 - - - point to the zone, yet use a DNSKEY with the SEP bit set to sign all - RRsets in the zone (other than the DNSKEY RRset). It's also possible - to use a single DNSKEY, with or without the SEP bit set, to sign the - entire zone, including the DNSKEY RRset itself. - -4.3 Errors in Examples - - The text in RFC4035 Section C.1 refers to the examples in B.1 as - "x.w.example.com" while B.1 uses "x.w.example". This is painfully - obvious in the second paragraph where it states that the RRSIG labels - field value of 3 indicates that the answer was not the result of - wildcard expansion. This is true for "x.w.example" but not for - "x.w.example.com", which of course has a label count of 4 - (antithetically, a label count of 3 would imply the answer was the - result of a wildcard expansion). - - The first paragraph of RFC4035 Section C.6 also has a minor error: - the reference to "a.z.w.w.example" should instead be "a.z.w.example", - as in the previous line. - -5. IANA Considerations - - This document specifies no IANA Actions. - -6. Security Considerations - - This document does not make fundamental changes to the DNSSEC - protocol, as it was generally understood when DNSSECbis was - published. It does, however, address some ambiguities and omissions - in those documents that, if not recognized and addressed in - implementations, could lead to security failures. In particular, the - validation algorithm clarifications in Section 2 are critical for - preserving the security properties DNSSEC offers. Furthermore, - failure to address some of the interoperability concerns in Section 3 - could limit the ability to later change or expand DNSSEC, including - by adding new algorithms. - -7. References - -7.1 Normative References - - [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. - - [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - - -Weiler Expires November 24, 2005 [Page 8] - -Internet-Draft DNSSECbis Implementation Notes May 2005 - - - [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Protocol Modifications for the DNS Security Extensions", - RFC 4035, March 2005. - - [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - -7.2 Informative References - - [5] Blacka, D., "DNSSEC Experiments", - draft-blacka-dnssec-experiments-00 (work in progress), - December 2004. - - [6] Gieben, R. and O. Kolkman, "DNSSEC Operational Practices", - draft-ietf-dnsop-dnssec-operational-practices-04 (work in - progress), May 2005. - - -Author's Address - - Samuel Weiler - SPARTA, Inc - 7075 Samuel Morse Drive - Columbia, Maryland 21046 - US - - Email: weiler@tislabs.com - -Appendix A. Acknowledgments - - The editor is extremely grateful to those who, in addition to finding - errors and omissions in the DNSSECbis document set, have provided - text suitable for inclusion in this document. - - The lack of specificity about handling private algorithms, as - described in Section 3.2, and the lack of specificity in handling ANY - queries, as described in Section 2.3, were discovered by David - Blacka. - - The error in algorithm 1 key tag calculation, as described in - Section 3.4, was found by Abhijit Hayatnagarkar. Donald Eastlake - contributed text for Section 3.4. - - The bug relating to delegation NSEC RR's in Section 2.1 was found by - Roy Badami. Roy Arends found the related problem with DNAME. - - The errors in the RFC4035 examples were found by Roy Arends, who also - contributed text for Section 4.3 of this document. - - - -Weiler Expires November 24, 2005 [Page 9] - -Internet-Draft DNSSECbis Implementation Notes May 2005 - - - The editor would like to thank Olafur Gudmundsson and Scott Rose for - their substantive comments on the text of this document. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Weiler Expires November 24, 2005 [Page 10] - -Internet-Draft DNSSECbis Implementation Notes May 2005 - - -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 - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2005). 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. - - - - -Weiler Expires November 24, 2005 [Page 11] - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-08.txt b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-08.txt new file mode 100644 index 0000000000..dc108cbf83 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-08.txt @@ -0,0 +1,672 @@ + + + +Network Working Group S. Weiler +Internet-Draft SPARTA, Inc. +Updates: 4033, 4034, 4035, 5155 D. Blacka +(if approved) VeriSign, Inc. +Intended status: Standards Track January 14, 2009 +Expires: July 18, 2009 + + + Clarifications and Implementation Notes for DNSSECbis + draft-ietf-dnsext-dnssec-bis-updates-08 + +Status of this Memo + + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and 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 July 18, 2009. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + + + + + + +Weiler & Blacka Expires July 18, 2009 [Page 1] + +Internet-Draft DNSSECbis Implementation Notes January 2009 + + +Abstract + + This document is a collection of technical clarifications to the + DNSSECbis document set. It is meant to serve as a resource to + implementors as well as a repository of DNSSECbis errata. + + +Table of Contents + + 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 3 + 1.1. Structure of this Document . . . . . . . . . . . . . . . . 3 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Important Additions to DNSSSECbis . . . . . . . . . . . . . . 3 + 2.1. NSEC3 Support . . . . . . . . . . . . . . . . . . . . . . 3 + 2.2. SHA-256 Support . . . . . . . . . . . . . . . . . . . . . 3 + 3. Significant Concerns . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 4 + 3.2. Validating Responses to an ANY Query . . . . . . . . . . . 4 + 3.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 5 + 3.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 5 + 3.5. Errors in Canonical Form Type Code List . . . . . . . . . 5 + 4. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5 + 4.1. Unknown DS Message Digest Algorithms . . . . . . . . . . . 5 + 4.2. Private Algorithms . . . . . . . . . . . . . . . . . . . . 6 + 4.3. Caution About Local Policy and Multiple RRSIGs . . . . . . 6 + 4.4. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7 + 4.5. Setting the DO Bit on Replies . . . . . . . . . . . . . . 7 + 4.6. Setting the AD bit on Replies . . . . . . . . . . . . . . 7 + 4.7. Setting the CD bit on Requests . . . . . . . . . . . . . . 8 + 4.8. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 8 + 5. Minor Corrections and Clarifications . . . . . . . . . . . . . 8 + 5.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 8 + 5.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 8 + 5.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 9 + 5.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 9 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 + + + + + + + + + +Weiler & Blacka Expires July 18, 2009 [Page 2] + +Internet-Draft DNSSECbis Implementation Notes January 2009 + + +1. Introduction and Terminology + + This document lists some clarifications and corrections to DNSSECbis, + as described in [RFC4033], [RFC4034], and [RFC4035]. + + It is intended to serve as a resource for implementors and as a + repository of items that need to be addressed when advancing the + DNSSECbis documents from Proposed Standard to Draft Standard. + +1.1. Structure of this Document + + The clarifications to DNSSECbis are sorted according to their + importance, starting with ones which could, if ignored, lead to + security and stability problems and progressing down to + clarifications that are expected to have little operational impact. + +1.2. Terminology + + 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]. + + +2. Important Additions to DNSSSECbis + + This section provides + +2.1. NSEC3 Support + + [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM + records for hashed denial of existence. Validator implementations + are strongly encouraged to include support for NSEC3 as a number of + highly visible zones are expected to use it. Validators that do not + support validation of responses using NSEC3 will likely be hampered + in validating large portions of the DNS space. + + [RFC5155] should be considered part of the DNS Security Document + Family as described by [RFC4033], Section 10. + +2.2. SHA-256 Support + + [RFC4509] describes the use of SHA-256 as a digest algorithm for use + with Delegation Signer (DS) RRs. [I-D.ietf-dnsext-dnssec-rsasha256] + describes the use of the RSASHA256 algorthim for use in DNSKEY and + RRSIG RRs. Validator implementations are strongly encouraged to + include support for this algorithm for DS, DNSKEY, and RRSIG records. + + Both [RFC4509] and [I-D.ietf-dnsext-dnssec-rsasha256] should also be + + + +Weiler & Blacka Expires July 18, 2009 [Page 3] + +Internet-Draft DNSSECbis Implementation Notes January 2009 + + + considered part of the DNS Security Document Family as described by + [RFC4033], Section 10. + + +3. Significant Concerns + + This section provides clarifications that, if overlooked, could lead + to security issues or major interoperability problems. + +3.1. Clarifications on Non-Existence Proofs + + [RFC4035] Section 5.4 underspecifies the algorithm for checking non- + existence proofs. In particular, the algorithm as presented would + incorrectly allow an NSEC or NSEC3 RR from an ancestor zone to prove + the non-existence of other RRs at that name in the child zone or + other names in the child zone. + + An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with: + + o the NS bit set, + o the SOA bit clear, and + o a signer field that is shorter than the owner name of the NSEC RR, + or the original owner name for the NSEC3 RR. + + Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume non- + existence of any RRs below that zone cut, which include all RRs at + that (original) owner name other than DS RRs, and all RRs below that + owner name regardless of type. + + Similarly, the algorithm would also allow an NSEC RR at the same + owner name as a DNAME RR, or an NSEC3 RR at the same original owner + name as a DNAME, to prove the non-existence of names beneath that + DNAME. An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used + to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's + (original) owner name. + +3.2. Validating Responses to an ANY Query + + [RFC4035] does not address how to validate responses when QTYPE=*. + As described in Section 6.2.2 of [RFC1034], a proper response to + QTYPE=* may include a subset of the RRsets at a given name -- it is + not necessary to include all RRsets at the QNAME in the response. + + When validating a response to QTYPE=*, validate all received RRsets + that match QNAME and QCLASS. If any of those RRsets fail validation, + treat the answer as Bogus. If there are no RRsets matching QNAME and + QCLASS, validate that fact using the rules in [RFC4035] Section 5.4 + (as clarified in this document). To be clear, a validator must not + + + +Weiler & Blacka Expires July 18, 2009 [Page 4] + +Internet-Draft DNSSECbis Implementation Notes January 2009 + + + expect to receive all records at the QNAME in response to QTYPE=*. + +3.3. Check for CNAME + + Section 5 of [RFC4035] says little about validating responses based + on (or that should be based on) CNAMEs. When validating a NOERROR/ + NODATA response, validators MUST check the CNAME bit in the matching + NSEC or NSEC3 RR's type bitmap. If the CNAME bit is set, the + validator MUST validate the CNAME RR and follow it, as appropriate. + +3.4. Insecure Delegation Proofs + + [RFC4035] Section 5.2 specifies that a validator, when proving a + delegation is not secure, needs to check for the absence of the DS + and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also + needs to check for the presence of the NS bit in the NSEC (or NSEC3) + RR (proving that there is, indeed, a delegation). If this is not + checked, spoofed unsigned delegations might be used to claim that an + existing signed record is not signed. + +3.5. Errors in Canonical Form Type Code List + + When canonicalizing DNS names, DNS names in the RDATA section of NSEC + and RRSIG resource records are not downcased. + + [RFC4034] Section 6.2 item 3 has a list of resource record types for + which DNS names in the RDATA are downcased for purposes of DNSSEC + canonical form (for both ordering and signing). That list + erroneously contains NSEC and RRSIG. According to [RFC3755], DNS + names in the RDATA of NSEC and RRSIG should not be downcased. + + The same section also erroneously lists HINFO, and twice at that. + Since HINFO records contain no domain names, they are not subject to + downcasing. + + +4. Interoperability Concerns + +4.1. Unknown DS Message Digest Algorithms + + Section 5.2 of [RFC4035] includes rules for how to handle delegations + to zones that are signed with entirely unsupported algorithms, as + indicated by the algorithms shown in those zone's DS RRsets. It does + not explicitly address how to handle DS records that use unsupported + message digest algorithms. In brief, DS records using unknown or + unsupported message digest algorithms MUST be treated the same way as + DS records referring to DNSKEY RRs of unknown or unsupported + algorithms. + + + +Weiler & Blacka Expires July 18, 2009 [Page 5] + +Internet-Draft DNSSECbis Implementation Notes January 2009 + + + The existing text says: + + If the validator does not support any of the algorithms listed in + an authenticated DS RRset, then the resolver has no supported + authentication path leading from the parent to the child. The + resolver should treat this case as it would the case of an + authenticated NSEC RRset proving that no DS RRset exists, as + described above. + + To paraphrase the above, when determining the security status of a + zone, a validator discards (for this purpose only) any DS records + listing unknown or unsupported algorithms. If none are left, the + zone is treated as if it were unsigned. + + Modified to consider DS message digest algorithms, a validator also + discards any DS records using unknown or unsupported message digest + algorithms. + +4.2. Private Algorithms + + As discussed above, section 5.2 of [RFC4035] requires that validators + make decisions about the security status of zones based on the public + key algorithms shown in the DS records for those zones. In the case + of private algorithms, as described in [RFC4034] Appendix A.1.1, the + eight-bit algorithm field in the DS RR is not conclusive about what + algorithm(s) is actually in use. + + If no private algorithms appear in the DS set or if any supported + algorithm appears in the DS set, no special processing will be + needed. In the remaining cases, the security status of the zone + depends on whether or not the resolver supports any of the private + algorithms in use (provided that these DS records use supported hash + functions, as discussed in Section 4.1). In these cases, the + resolver MUST retrieve the corresponding DNSKEY for each private + algorithm DS record and examine the public key field to determine the + algorithm in use. The security-aware resolver MUST ensure that the + hash of the DNSKEY RR's owner name and RDATA matches the digest in + the DS RR. If they do not match, and no other DS establishes that + the zone is secure, the referral should be considered BAD data, as + discussed in [RFC4035]. + + This clarification facilitates the broader use of private algorithms, + as suggested by [RFC4955]. + +4.3. Caution About Local Policy and Multiple RRSIGs + + When multiple RRSIGs cover a given RRset, [RFC4035] Section 5.3.3 + suggests that "the local resolver security policy determines whether + + + +Weiler & Blacka Expires July 18, 2009 [Page 6] + +Internet-Draft DNSSECbis Implementation Notes January 2009 + + + the resolver also has to test these RRSIG RRs and how to resolve + conflicts if these RRSIG RRs lead to differing results." In most + cases, a resolver would be well advised to accept any valid RRSIG as + sufficient. If the first RRSIG tested fails validation, a resolver + would be well advised to try others, giving a successful validation + result if any can be validated and giving a failure only if all + RRSIGs fail validation. + + If a resolver adopts a more restrictive policy, there's a danger that + properly-signed data might unnecessarily fail validation, perhaps + because of cache timing issues. Furthermore, certain zone management + techniques, like the Double Signature Zone-signing Key Rollover + method described in section 4.2.1.2 of [RFC4641] might not work + reliably. + +4.4. Key Tag Calculation + + [RFC4034] Appendix B.1 incorrectly defines the Key Tag field + calculation for algorithm 1. It correctly says that the Key Tag is + the most significant 16 of the least significant 24 bits of the + public key modulus. However, [RFC4034] then goes on to incorrectly + say that this is 4th to last and 3rd to last octets of the public key + modulus. It is, in fact, the 3rd to last and 2nd to last octets. + +4.5. Setting the DO Bit on Replies + + [RFC4035] does not provide any instructions to servers as to how to + set the DO bit. Some authoritative server implementations have + chosen to copy the DO bit settings from the incoming query to the + outgoing response. Others have chosen to never set the DO bit in + responses. Either behavior is permitted. To be clear, in replies to + queries with the DO-bit set servers may or may not set the DO bit. + +4.6. Setting the AD bit on Replies + + Section 3.2.3 of [RFC4035] describes under which conditions a + validating resolver should set or clear the AD bit in a response. In + order to protect legacy stub resolvers and middleboxes, validating + resolvers SHOULD only set the AD bit when a response both meets the + conditions listed in RFC 4035, section 3.2.3, and the request + contained either a set DO bit or a set AD bit. + + Note that the use of the AD bit in the query was previously + undefined. This document defines it as a signal indicating that the + requester understands and is interested in the value of the AD bit in + the response. This allows a requestor to indicate that it + understands the AD bit without also requesting DNSSEC data via the DO + bit. + + + +Weiler & Blacka Expires July 18, 2009 [Page 7] + +Internet-Draft DNSSECbis Implementation Notes January 2009 + + +4.7. Setting the CD bit on Requests + + When processing a request with the CD bit set, the resolver MUST set + the CD bit on its upstream queries. + +4.8. Nested Trust Anchors + + A DNSSEC validator may be configured such that, for a given response, + more than one trust anchor could be used to validate the chain of + trust to the response zone. For example, imagine a validor + configured with trust anchors for "example." and "zone.example." + When the validator is asked to validate a response to + "www.sub.zone.example.", either trust anchor could apply. + + When presented with this situation, DNSSEC validators SHOULD try all + applicable trust anchors until one succeeds. + + There are some scenarios where different behaviors, such as choosing + the trust anchor closest to the QNAME of the response, may be + desired. A DNSSEC validator MAY enable such behaviors as + configurable overrides. + + +5. Minor Corrections and Clarifications + +5.1. Finding Zone Cuts + + Appendix C.8 of [RFC4035] discusses sending DS queries to the servers + for a parent zone. To do that, a resolver may first need to apply + special rules to discover what those servers are. + + As explained in Section 3.1.4.1 of [RFC4035], security-aware name + servers need to apply special processing rules to handle the DS RR, + and in some situations the resolver may also need to apply special + rules to locate the name servers for the parent zone if the resolver + does not already have the parent's NS RRset. Section 4.2 of + [RFC4035] specifies a mechanism for doing that. + +5.2. Clarifications on DNSKEY Usage + + Questions of the form "can I use a different DNSKEY for signing this + RRset" have occasionally arisen. + + The short answer is "yes, absolutely". You can even use a different + DNSKEY for each RRset in a zone, subject only to practical limits on + the size of the DNSKEY RRset. However, be aware that there is no way + to tell resolvers what a particularly DNSKEY is supposed to be used + for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to + + + +Weiler & Blacka Expires July 18, 2009 [Page 8] + +Internet-Draft DNSSECbis Implementation Notes January 2009 + + + authenticate any RRset in the zone. For example, if a weaker or less + trusted DNSKEY is being used to authenticate NSEC RRsets or all + dynamically updated records, that same DNSKEY can also be used to + sign any other RRsets from the zone. + + Furthermore, note that the SEP bit setting has no effect on how a + DNSKEY may be used -- the validation process is specifically + prohibited from using that bit by [RFC4034] section 2.1.2. It is + possible to use a DNSKEY without the SEP bit set as the sole secure + entry point to the zone, yet use a DNSKEY with the SEP bit set to + sign all RRsets in the zone (other than the DNSKEY RRset). It's also + possible to use a single DNSKEY, with or without the SEP bit set, to + sign the entire zone, including the DNSKEY RRset itself. + +5.3. Errors in Examples + + The text in [RFC4035] Section C.1 refers to the examples in B.1 as + "x.w.example.com" while B.1 uses "x.w.example". This is painfully + obvious in the second paragraph where it states that the RRSIG labels + field value of 3 indicates that the answer was not the result of + wildcard expansion. This is true for "x.w.example" but not for + "x.w.example.com", which of course has a label count of 4 + (antithetically, a label count of 3 would imply the answer was the + result of a wildcard expansion). + + The first paragraph of [RFC4035] Section C.6 also has a minor error: + the reference to "a.z.w.w.example" should instead be "a.z.w.example", + as in the previous line. + +5.4. Errors in RFC 5155 + + A NSEC3 record, that matches an Empty Non-Terminal, effectively has + no type associated with it. This NSEC3 record has an empty type bit + map. Section 3.2.1 of [RFC5155] contains the statement: + + Blocks with no types present MUST NOT be included. + + However, the same section contains a regular expression: + + Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ + + The plus sign in the regular expression indicates that there is one + or more of the preceding element. This means that there must be at + least one window block. If this window block has no types, it + contradicts with the first statement. Therefore, the correct text in + RFC 5155 3.2.1 should be: + + + + + +Weiler & Blacka Expires July 18, 2009 [Page 9] + +Internet-Draft DNSSECbis Implementation Notes January 2009 + + + Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )* + + +6. IANA Considerations + + This document specifies no IANA Actions. + + +7. Security Considerations + + This document does not make fundamental changes to the DNSSEC + protocol, as it was generally understood when DNSSECbis was + published. It does, however, address some ambiguities and omissions + in those documents that, if not recognized and addressed in + implementations, could lead to security failures. In particular, the + validation algorithm clarifications in Section 3 are critical for + preserving the security properties DNSSEC offers. Furthermore, + failure to address some of the interoperability concerns in Section 4 + could limit the ability to later change or expand DNSSEC, including + by adding new algorithms. + + +8. References + +8.1. Normative References + + [I-D.ietf-dnsext-dnssec-rsasha256] + Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY + and RRSIG Resource Records for DNSSEC", + draft-ietf-dnsext-dnssec-rsasha256-10 (work in progress), + January 2009. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + RFC 1034, STD 13, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, BCP 14, March 1997. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + + + +Weiler & Blacka Expires July 18, 2009 [Page 10] + +Internet-Draft DNSSECbis Implementation Notes January 2009 + + + Extensions", RFC 4035, March 2005. + + [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer + (DS) Resource Records (RRs)", RFC 4509, May 2006. + + [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS + Security (DNSSEC) Hashed Authenticated Denial of + Existence", RFC 5155, March 2008. + +8.2. Informative References + + [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer (DS)", RFC 3755, May 2004. + + [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", + RFC 4641, September 2006. + + [RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955, + July 2007. + + +Appendix A. Acknowledgments + + The editors would like the thank Rob Austein for his previous work as + an editor of this document. + + The editors are extremely grateful to those who, in addition to + finding errors and omissions in the DNSSECbis document set, have + provided text suitable for inclusion in this document. + + The lack of specificity about handling private algorithms, as + described in Section 4.2, and the lack of specificity in handling ANY + queries, as described in Section 3.2, were discovered by David + Blacka. + + The error in algorithm 1 key tag calculation, as described in + Section 4.4, was found by Abhijit Hayatnagarkar. Donald Eastlake + contributed text for Section 4.4. + + The bug relating to delegation NSEC RR's in Section 3.1 was found by + Roy Badami. Roy Arends found the related problem with DNAME. + + The errors in the [RFC4035] examples were found by Roy Arends, who + also contributed text for Section 5.3 of this document. + + The editors would like to thank Ed Lewis, Danny Mayer, Olafur + Gudmundsson, Suzanne Woolf, and Scott Rose for their substantive + comments on the text of this document. + + + +Weiler & Blacka Expires July 18, 2009 [Page 11] + +Internet-Draft DNSSECbis Implementation Notes January 2009 + + +Authors' Addresses + + Samuel Weiler + SPARTA, Inc. + 7110 Samuel Morse Drive + Columbia, Maryland 21046 + US + + Email: weiler@tislabs.com + + + David Blacka + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166 + US + + Email: davidb@verisign.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Weiler & Blacka Expires July 18, 2009 [Page 12] +