draft-ietf-dnsext-dnssec-bis-updates-12.txt   draft-ietf-dnsext-dnssec-bis-updates-13.txt 
Network Working Group S. Weiler Network Working Group S. Weiler
Internet-Draft SPARTA, Inc. Internet-Draft SPARTA, Inc.
Updates: 4033, 4034, 4035, 5155 D. Blacka Updates: 4033, 4034, 4035, 5155 D. Blacka
(if approved) VeriSign, Inc. (if approved) VeriSign, Inc.
Intended status: Standards Track November 10, 2010 Intended status: Standards Track July 10, 2011
Expires: May 14, 2011 Expires: January 11, 2012
Clarifications and Implementation Notes for DNSSECbis Clarifications and Implementation Notes for DNSSECbis
draft-ietf-dnsext-dnssec-bis-updates-12 draft-ietf-dnsext-dnssec-bis-updates-13
Abstract Abstract
This document is a collection of technical clarifications to the This document is a collection of technical clarifications to the
DNSSECbis document set. It is meant to serve as a resource to DNSSECbis document set. It is meant to serve as a resource to
implementors as well as a repository of DNSSECbis errata. implementors as well as a repository of DNSSECbis errata.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 14, 2011. This Internet-Draft will expire on January 11, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 29 skipping to change at page 2, line 29
4.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 5 4.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 5
5. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5 5. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5
5.1. Errors in Canonical Form Type Code List . . . . . . . . . 6 5.1. Errors in Canonical Form Type Code List . . . . . . . . . 6
5.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 6 5.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 6
5.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 6 5.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 6
5.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 7 5.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 7
5.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7 5.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7
5.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 8 5.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 8
5.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 8 5.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 8
5.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 8 5.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 8
5.9. Handling Queries With the CD Bit Set . . . . . . . . . . . 8 5.9. Always set the CD bit on Queries . . . . . . . . . . . . . 8
5.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 9 5.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 9
5.10.1. Closest Encloser . . . . . . . . . . . . . . . . . . 9 5.10.1. Closest Encloser . . . . . . . . . . . . . . . . . . 9
5.10.2. Accept Any Success . . . . . . . . . . . . . . . . . 9 5.10.2. Accept Any Success . . . . . . . . . . . . . . . . . 9
5.10.3. Preference Based on Source . . . . . . . . . . . . . 10 5.10.3. Preference Based on Source . . . . . . . . . . . . . 10
6. Minor Corrections and Clarifications . . . . . . . . . . . . . 10 5.11. Mandatory Algorithm Rules . . . . . . . . . . . . . . . . 10
6.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 10 5.12. Expect Extra Signatures From Strange Keys . . . . . . . . 11
6.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 11 6. Minor Corrections and Clarifications . . . . . . . . . . . . . 11
6.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 11 6.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 11
6.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 11 6.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction and Terminology 1. Introduction and Terminology
This document lists some additions, clarifications and corrections to This document lists some additions, clarifications and corrections to
the core DNSSECbis specification, as originally described in the core DNSSECbis specification, as originally described in
[RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155]. [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155].
(See section Section 2 for more recent additions to that core (See section Section 2 for more recent additions to that core
document set.) document set.)
It is intended to serve as a resource for implementors and as a It is intended to serve as a resource for implementors and as a
skipping to change at page 8, line 29 skipping to change at page 8, line 29
5.8. Setting the AD Bit on Replies 5.8. Setting the AD Bit on Replies
Section 3.2.3 of [RFC4035] describes under which conditions a Section 3.2.3 of [RFC4035] describes under which conditions a
validating resolver should set or clear the AD bit in a response. In validating resolver should set or clear the AD bit in a response. In
order to protect legacy stub resolvers and middleboxes, validating order to protect legacy stub resolvers and middleboxes, validating
resolvers SHOULD only set the AD bit when a response both meets the 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 conditions listed in RFC 4035, section 3.2.3, and the request
contained either a set DO bit or a set AD bit. contained either a set DO bit or a set AD bit.
5.9. Handling Queries With the CD Bit Set 5.9. Always set the CD bit on Queries
When processing a request with the CD bit set, a resolver SHOULD When processing a request with the CD bit set, a resolver SHOULD
attempt to return all responsive data, even data that has failed attempt to return all responsive data, even data that has failed
DNSSEC validation. RFC4035 section 3.2.2 requires a resolver DNSSEC validation. RFC4035 section 3.2.2 requires a resolver
processing a request with the CD bit set to set the CD bit on its processing a request with the CD bit set to set the CD bit on its
upstream queries. upstream queries.
The guidance in RFC4035 is ambiguous about what to do when a cached Prevailing wisdom suggests that a validating resolver SHOULD set the
response was obtained with the CD bit not set. In the typical case, CD bit on every upstream query regardless of whether the CD bit was
no new query is required, nor does the cache need to track the state set on the incoming query or whether it has a trust anchor at or
of the CD bit used to make a given query. The problem arises when above the QNAME. In other words, a validating resolver should
the cached response is a server failure (RCODE 2), which may indicate attempt to retrieve all possible data -- even that which it can not
that the requested data failed DNSSEC validation at an upstream validate itself -- on the grounds that a later query might come with
validating resolver. (RFC2308 permits caching of server failures for the CD bit set.
up to five minutes.) In these cases, a new query with the CD bit set
is required.
For efficiency, a validator SHOULD set the CD bit on upstream queries RFC4035 is ambiguous about what to do when a cached response was
when it has a trust anchor at or above the QNAME (and thus can obtained with the CD bit not set, a case that only arises when the
reasonably expect to be able to validate the response). resolver chooses not to set the CD bit on all upstream queries, as
suggested above. In the typical case, no new query is required, nor
does the cache need to track the state of the CD bit used to make a
given query. The problem arises when the cached response is a server
failure (RCODE 2), which may indicate that the requested data failed
DNSSEC validation at an upstream validating resolver. (RFC2308
permits caching of server failures for up to five minutes.) In these
cases, a new query with the CD bit set is required.
5.10. Nested Trust Anchors 5.10. Nested Trust Anchors
A DNSSEC validator may be configured such that, for a given response, 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 more than one trust anchor could be used to validate the chain of
trust to the response zone. For example, imagine a validator trust to the response zone. For example, imagine a validator
configured with trust anchors for "example." and "zone.example." configured with trust anchors for "example." and "zone.example."
When the validator is asked to validate a response to When the validator is asked to validate a response to
"www.sub.zone.example.", either trust anchor could apply. "www.sub.zone.example.", either trust anchor could apply.
skipping to change at page 10, line 39 skipping to change at page 10, line 43
that the manually configured ones have been more carefully that the manually configured ones have been more carefully
authenticated. authenticated.
Or the validator might do something more complicated: prefer a sub- Or the validator might do something more complicated: prefer a sub-
set of manually configured trust anchors (based on a configuration set of manually configured trust anchors (based on a configuration
option), then trust anchors that have been updated using the RFC5011 option), then trust anchors that have been updated using the RFC5011
mechanism, then trust anchors from one DLV registry, then trust mechanism, then trust anchors from one DLV registry, then trust
anchors from a different DLV registry, then the rest of the manually anchors from a different DLV registry, then the rest of the manually
configured trust anchors. configured trust anchors.
5.11. Mandatory Algorithm Rules
The last paragraph of RFC4035 Section 2.2 includes rules for which
algorithms must be used to sign a zone. Since these rules have been
confusing, we restate them in different language here:
The DS RRset and DNSKEY RRset are used to signal which algorithms
are used to sign a zone. The pressence of an algorithm in a
zone's DS or DNSKEY RRset set signals that that algorithm is used
to sign the entire zone.
A signed zone MUST include a DNSKEY for each algorithm present in
the zone's DS RRset and expected trust anchors for the zone. The
zone MUST also be signed with each algorithm (though not each key)
present in the DNSKEY RRset. It is possible to add algorithms at
the DNSKEY that aren't in the DS record, but not vice-versa. If
more than one key of the same algorithm is in the DNSKEY RRset, it
is sufficient to sign each RRset with any subset of these DNSKEYs.
It is acceptable to sign some RRsets with one subset of keys (or
key) and other RRsets with a different subset, so long as at least
one DNSKEY of each algorithm is used to sign each RRset.
Likewise, if there are DS records for multiple keys of the same
algorithm, any subset of those may appear in the DNSKEY RRset.
Lastly, note that this a requirement at the server side, not the
client side. Validators SHOULD accept any single valid path. They
SHOULD NOT insist that all algorithms signalled in the DS RRset work,
and they MUST NOT insist that all algorithms signalled in the DNSKEY
RRset work. A validator MAY have a configuration option to perform a
signature completeness test to support troubleshooting.
5.12. Expect Extra Signatures From Strange Keys
Validating resolvers should not be surprised to find RRSIGs in a zone
that do not (currently) have a corresponding DNSKEY in the zone.
Likewise, a validating resolver should not be surprised to find
RRSIGs with algorithm types that don't exist in the DNSKEY RRset or
DNSKEYs with algorithm types that don't appear in the zone's DS
RRset.
Good key rollover and algorithm rollover practices, as discussed in
RFC4641 and its successor documents and as suggested by the rules in
the previous section, may require that such RRSIGs be present in a
zone.
6. Minor Corrections and Clarifications 6. Minor Corrections and Clarifications
6.1. Finding Zone Cuts 6.1. Finding Zone Cuts
Appendix C.8 of [RFC4035] discusses sending DS queries to the servers 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 for a parent zone. To do that, a resolver may first need to apply
special rules to discover what those servers are. special rules to discover what those servers are.
As explained in Section 3.1.4.1 of [RFC4035], security-aware name 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, servers need to apply special processing rules to handle the DS RR,
skipping to change at page 11, line 27 skipping to change at page 12, line 28
authenticate any RRset in the zone. For example, if a weaker or less authenticate any RRset in the zone. For example, if a weaker or less
trusted DNSKEY is being used to authenticate NSEC RRsets or all trusted DNSKEY is being used to authenticate NSEC RRsets or all
dynamically updated records, that same DNSKEY can also be used to dynamically updated records, that same DNSKEY can also be used to
sign any other RRsets from the zone. sign any other RRsets from the zone.
Furthermore, note that the SEP bit setting has no effect on how a Furthermore, note that the SEP bit setting has no effect on how a
DNSKEY may be used -- the validation process is specifically DNSKEY may be used -- the validation process is specifically
prohibited from using that bit by [RFC4034] section 2.1.2. It is 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 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 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 sign all RRsets in the zone (other than the DNSKEY RRset). It is
possible to use a single DNSKEY, with or without the SEP bit set, to also possible to use a single DNSKEY, with or without the SEP bit
sign the entire zone, including the DNSKEY RRset itself. set, to sign the entire zone, including the DNSKEY RRset itself.
6.3. Errors in Examples 6.3. Errors in Examples
The text in [RFC4035] Section C.1 refers to the examples in B.1 as 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 "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 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 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 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 "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 (antithetically, a label count of 3 would imply the answer was the
skipping to change at page 14, line 20 skipping to change at page 15, line 20
The error in algorithm 1 key tag calculation, as described in The error in algorithm 1 key tag calculation, as described in
Section 5.5, was found by Abhijit Hayatnagarkar. Donald Eastlake Section 5.5, was found by Abhijit Hayatnagarkar. Donald Eastlake
contributed text for Section 5.5. contributed text for Section 5.5.
The bug relating to delegation NSEC RR's in Section 4.1 was found by The bug relating to delegation NSEC RR's in Section 4.1 was found by
Roy Badami. Roy Arends found the related problem with DNAME. Roy Badami. Roy Arends found the related problem with DNAME.
The errors in the [RFC4035] examples were found by Roy Arends, who The errors in the [RFC4035] examples were found by Roy Arends, who
also contributed text for Section 6.3 of this document. also contributed text for Section 6.3 of this document.
Text on the mandatory algorithm rules was derived from suggestions by
Matthijs Mekking and Ed Lewis.
The CD bit logic was analyzed in depth by David Blacka, Olafur
Gudmundsson, Mike St. Johns, and Andrew Sullivan.
The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer, The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer,
Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns, Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns,
Mark Andrews, Wouter Wijngaards, Matthijs Mekking, Andrew Sullivan,
and Scott Rose for their substantive comments on the text of this and Scott Rose for their substantive comments on the text of this
document. document.
Authors' Addresses Authors' Addresses
Samuel Weiler Samuel Weiler
SPARTA, Inc. SPARTA, Inc.
7110 Samuel Morse Drive 7110 Samuel Morse Drive
Columbia, Maryland 21046 Columbia, Maryland 21046
US US
 End of changes. 13 change blocks. 
34 lines changed or deleted 93 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/