617 lines
21 KiB
Plaintext
617 lines
21 KiB
Plaintext
|
||
|
||
|
||
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]
|
||
|