📄 draft-ietf-dnsext-dnssec-bis-updates-01.txt
字号:
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 thatWeiler 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 Clarifications4.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 entryWeiler 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. References7.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.comAppendix 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 2005Intellectual 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] ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -