< draft-ietf-dnsext-rollover-requirements-03.txt   draft-ietf-dnsext-rollover-requirements-04.txt >
Network Working Group H. Eland Network Working Group H. Eland
Internet-Draft Afilias Limited Internet-Draft Afilias Limited
Intended status: Informational R. Mundy Intended status: Informational R. Mundy
Expires: March 5, 2007 SPARTA, Inc. Expires: May 31, 2007 SPARTA, Inc.
S. Crocker S. Crocker
Shinkuro Inc. Shinkuro Inc.
S. Krishnaswamy S. Krishnaswamy
SPARTA, Inc. SPARTA, Inc.
Sept 2006 November 27, 2006
Requirements related to DNSSEC Trust Anchor Rollover Requirements related to DNSSEC Trust Anchor Rollover
draft-ietf-dnsext-rollover-requirements-03 draft-ietf-dnsext-rollover-requirements-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 5, 2007. This Internet-Draft will expire on May 31, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Every DNS security-aware resolver must have at least one Trust Anchor Every DNS security-aware resolver must have at least one Trust Anchor
to use as the basis for validating responses from DNS signed zones. to use as the basis for validating responses from DNS signed zones.
For various reasons, most DNS security-aware resolvers are expected For various reasons, most DNS security-aware resolvers are expected
to have several Trust Anchors. For some operations, manual to have several Trust Anchors. For some operations, manual
monitoring and updating of Trust Anchors may be feasible but many monitoring and updating of Trust Anchors may be feasible but many
operations will require automated methods for updating Trust Anchors operations will require automated methods for updating Trust Anchors
in their security-aware resolvers. This document identifies the in their security-aware resolvers. This document identifies the
requirements that must be met by an automated DNS Trust Anchor requirements that must be met by an automated DNS Trust Anchor
rollover solution for security-aware DNS resolvers. rollover solution for security-aware DNS resolvers.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 5 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 5.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. No Intellectual Property Encumbrance . . . . . . . . . . . 7 5.2 No Intellectual Property Encumbrance . . . . . . . . . . . 7
5.3. General Applicability . . . . . . . . . . . . . . . . . . 7 5.3 General Applicability . . . . . . . . . . . . . . . . . . . 7
5.4. Support Private Networks . . . . . . . . . . . . . . . . . 7 5.4 Support Private Networks . . . . . . . . . . . . . . . . . 7
5.5. Detection of Stale Trust Anchors . . . . . . . . . . . . . 7 5.5 Detection of Stale Trust Anchors . . . . . . . . . . . . . 7
5.6. Manual Operations Permitted . . . . . . . . . . . . . . . 7 5.6 Manual Operations Permitted . . . . . . . . . . . . . . . . 7
5.7. Planned and Unplanned Rollovers . . . . . . . . . . . . . 8 5.7 Planned and Unplanned Rollovers . . . . . . . . . . . . . . 8
5.8. Timeliness . . . . . . . . . . . . . . . . . . . . . . . . 8 5.8 Timeliness . . . . . . . . . . . . . . . . . . . . . . . . 8
5.9. High Availability . . . . . . . . . . . . . . . . . . . . 8 5.9 High Availability . . . . . . . . . . . . . . . . . . . . . 8
5.10. New RR Types . . . . . . . . . . . . . . . . . . . . . . . 8 5.10 New RR Types . . . . . . . . . . . . . . . . . . . . . . . 8
5.11. Support for Trust Anchor Maintenance Operations . . . . . 8 5.11 Support for Trust Anchor Maintenance Operations . . . . . . 8
5.12. Recovery From Compromise . . . . . . . . . . . . . . . . . 8 5.12 Recovery From Compromise . . . . . . . . . . . . . . . . . 8
5.13. Non-degrading Trust . . . . . . . . . . . . . . . . . . . 9 5.13 Non-degrading Trust . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 9 Normative References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 11
1. Terminology 1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1]. document are to be interpreted as described in RFC-2119 [1].
The use of RFC-2119 words in the requirements is intended to The use of RFC-2119 words in the requirements is intended to
unambiguously describe a requirement. If a tradeoff is to be made unambiguously describe a requirement. If a tradeoff is to be made
between conflicting requirements when choosing a solution the between conflicting requirements when choosing a solution the
requirement with MUST language will have higher preference than requirement with MUST language will have higher preference than
requirements with SHOULD, MAY, or RECOMMEND language. It is requirements with SHOULD, MAY, or RECOMMEND language. It is
understood that a tradeoff may need to be made between requirements understood that a tradeoff may need to be made between requirements
that both contain RFC2119 language. that both contain RFC2119 language.
2. Introduction 2 Introduction
The Domain Name System Security Extensions (DNSSEC) as described in The Domain Name System Security Extensions (DNSSEC) as described in
[2] [3] and [4] defines new records and protocol modifications to DNS [2] [3] and [4] defines new records and protocol modifications to DNS
that permit security-aware resolvers to validate DNS Resource Records that permit security-aware resolvers to validate DNS Resource Records
(RRs) from one or more Trust Anchor(s) held by security-aware (RRs) from one or more Trust Anchors held by security-aware
resolvers. resolvers.
Security-aware resolvers will have to initially obtain their Trust Security-aware resolvers will have to initially obtain their Trust
Anchors in a trustworthy manner to ensure the Trust Anchors are Anchors in a trustworthy manner to ensure the Trust Anchors are
correct and valid. There are a number of ways that this initial step correct and valid. There are a number of ways that this initial step
can be accomplished however details of this step are beyond the scope can be accomplished however details of this step are beyond the scope
of this document. Once an operator has obtained Trust Anchors, of this document. Once an operator has obtained Trust Anchors,
initially entering the Trust Anchor(s) into their security-aware initially entering the Trust Anchors into their security-aware
resolvers will in many instances be a manual operation. resolvers will in many instances be a manual operation.
For some operational environments, manual management of Trust Anchors For some operational environments, manual management of Trust Anchors
might be a viable approach. However, many operational environments might be a viable approach. However, many operational environments
will require a more automated specification-based method for up- will require a more automated specification-based method for up-
dating and managing Trust Anchors. Several mechanisms for automated dating and managing Trust Anchors. Several mechanisms for automated
specification-based approaches have been proposed to the DNS specification-based approaches have been proposed to the DNS
Extensions (dnsext) Working Group but each seems to be solving a Extensions (dnsext) Working Group but each seems to be solving a
somewhat different group of requirements. As a result, the Working somewhat different group of requirements. As a result, the Working
Group determined that a requirements document needed to be developed Group determined that a requirements document needed to be developed
so that each of the proposed mechanisms can be measured against a so that each of the proposed mechanisms can be measured against a
consistent set of requirements. This document provides these Trust consistent set of requirements. This document provides these Trust
Anchor Rollover requirements. Anchor Rollover requirements.
3. Background 3 Background
DNS resolvers need to have one or more starting points to use in DNS resolvers need to have one or more starting points to use in
obtaining DNS answers. The starting points for stub resolvers is obtaining DNS answers. The starting points for stub resolvers are
normally the IP address for one or more recursive name servers. The normally the IP addresses for one or more recursive name servers.
starting points for recursive name servers are normally IP addresses The starting points for recursive name servers are normally IP
for DNS root name servers. Similarly, security-aware resolvers must addresses for DNS root name servers. Similarly, security-aware
have one or more starting points to use for building the resolvers must have one or more starting points to use for building
authenticated chain to validate a signed DNS response. Instead of IP the authenticated chain to validate a signed DNS response. Instead
addresses, DNSSEC requires that each operator of a security-aware of IP addresses, DNSSEC requires that each resolver trust one or more
resolver trust one or more DNSKEY RR or a DS RR hash of a DNSKEY RR DNSKEY RR or DS RR as their starting point. Each of these starting
as their starting point. Each of these starting points is called a points is called a Trust Anchor.
Trust Anchor.
It should be noted that DNSKEY RRs and DS RRs are not Trust Anchors It should be noted that DNSKEY RRs and DS RRs are not Trust Anchors
when they are created by the signed zone operation nor are they Trust when they are created by the signed zone operation nor are they Trust
Anchors because the records are published in the signed zone. A Anchors because the records are published in the signed zone. A
DNSKEY RR or DS RR becomes a Trust Anchor when an operator of a DNSKEY RR or DS RR becomes a Trust Anchor when an operator of a
security-aware resolver determines that the public key or hash will security-aware resolver determines that the public key or hash will
be used as a Trust Anchor. Thus the signed zone operation that be used as a Trust Anchor. Thus the signed zone operator that
created and/or published a DNSKEY RR (or DS RR) may not know if any created and/or published these RRs may not know if any of the DNSKEY
of the DNSKEY RRs or DS RRs associated with their zone are being used RRs or DS RRs associated with their zone are being used as Trust
as Trust Anchors by security aware resolvers. The obvious exceptions Anchors by security aware resolvers. The obvious exceptions are the
are the DNSKEY RRs for the root zone that will be used by many DNSKEY RR(s) for the root zone that will be used by many security-
security-aware resolvers. For various reasons, DNSKEY RRs or DS RRs aware resolvers. For various reasons, DNSKEY RRs or DS RRs from
from zones other than root can be used by operators of security-aware zones other than root can be used by operators of security-aware
resolvers as Trust Anchors. It follows that responsibility lies with resolvers as Trust Anchors. It follows that responsibility lies with
the operator of the security-aware resolver to ensure that the DNSKEY the operator of the security-aware resolver to ensure that the DNSKEY
RRs and/or DS RRs they have chosen to use as Trust Anchors are valid and/or DS RRs they have chosen to use as Trust Anchors are valid at
at the time they are used by the security-aware resolver as the the time they are used by the security-aware resolver as the starting
starting point for building the authentication chain to validate a point for building the authentication chain to validate a signed DNS
signed DNS response. response.
When operators of security-aware resolvers choose one or more Trust When operators of security-aware resolvers choose one or more Trust
Anchors, they must also determine the method(s) they will use to Anchors, they must also determine the method(s) they will use to
ensure that they are using valid RR(s) and that they are able to ensure that they are using valid RRs and that they are able to
determine when RR(s) being used as Trust Anchors should be replaced determine when RRs being used as Trust Anchors should be replaced or
or removed. Early adopters of DNS signed zones have published removed. Early adopters of DNS signed zones have published
information about the processes and methods they will use when their information about the processes and methods they will use when their
DNSKEY RRs and/or DS RR(s) change so that security-aware resolvers DNSKEY and/or DS RRs change so that operators of security-aware
can change their Trust Anchors at the appropriate time. This resolvers can change the Trust Anchors at the appropriate time. This
approach will not scale and, therefore, drives the need for an approach will not scale and, therefore, drives the need for an
automated specification-based approach for rollover of Trust Anchors automated specification-based approach for rollover of Trust Anchors
for security-aware resolvers. for security-aware resolvers.
4. Definitions 4 Definitions
This document uses the definitions contained in RFC-4033 section 2 This document uses the definitions contained in RFC-4033 section 2
plus the following additional definitions (Alphabetic by first word): plus the following additional definitions:
Trust Anchor: From RFC-4033, "A configured DNSKEY RR or DS RR hash Trust Anchor: From RFC-4033, "A configured DNSKEY RR or DS RR hash
of a DNSKEY RR. A validating security-aware resolver uses this of a DNSKEY RR. A validating security-aware resolver uses this
public key or hash as a starting point for building the public key or hash as a starting point for building the
authentication chain to a signed DNS response." Additionally, a authentication chain to a signed DNS response." Additionally, a
DNSKEY RR or DS RR hash of a DNSKEY RR is associated with DNSKEY RR or DS RR is associated with precisely one point in the
precisely one point in the DNS hierarchy, i.e., one DNS zone. DNS hierarchy, i.e., one DNS zone. Multiple Trust Anchors MAY may
Multiple Trust Anchors MAY may be associated with each DNS zone be associated with each DNS zone and MAY be held by any number of
and MAY be held by any number of security-aware resolvers. security-aware resolvers. Security-aware resolvers MAY have Trust
Security-aware resolvers MAY have Trust Anchor(s) from multiple Anchors from multiple DNS zones. Those responsible for operation
DNS zones. Those responsible for operation of security-aware of security-aware resolvers are responsible for determining which
resolvers are responsible for determining which RRs will be used RRs will be used for Trust Anchors by that resolver.
for Trust Anchors by that resolver.
Initial Trust Relationship: An operator of a security-aware resolver Initial Trust Relationship: An operator of a security-aware resolver
must ensure that they initially obtain any Trust Anchors in a must ensure that they initially obtain any Trust Anchors in a
trustworthy manner. For example, the correctness of the root zone trustworthy manner. For example, the correctness of the root zone
DNSKEY RR could be verified by comparing what the operator DNSKEY RR(s) could be verified by comparing what the operator
believes to be the root Trust Anchor with several 'well known' believes to be the root Trust Anchor(s) with several 'well known'
sources such as the IANA web site, the DNS published root zone and sources such as the IANA web site, the DNS published root zone and
the publication of the public key in well known hard-copy forms. the publication of the public key in well known hard-copy forms.
For other Trust Anchors, the operator must ensure the accuracy and For other Trust Anchors, the operator must ensure the accuracy and
validity of the DNSKEY RR or DS RR before designating them Trust validity of the DNSKEY and/or DS RRs before designating them Trust
Anchor(s). This might be accomplished through a combination of Anchors. This might be accomplished through a combination of
technical, procedural and contract relationships or use other technical, procedural and contract relationships or use other
existing trust relationships outside of the current DNS protocol. existing trust relationships outside of the current DNS protocol.
Trust Anchor Distribution: The method or methods used to convey the Trust Anchor Distribution: The method or methods used to convey the
DNSKEY RR(s) or DS RR(s) between the signed zone operation and the DNSKEY and/or DS RR(s) between the signed zone operation and the
security-aware resolver operation. The method or methods MUST be security-aware resolver operation. The method or methods MUST be
deemed sufficiently trustworthy by the operator of the security- deemed sufficiently trustworthy by the operator of the security-
aware resolver to ensure source authenticity and integrity of the aware resolver to ensure source authenticity and integrity of the
new RR(s) to maintain the Initial Trust Relationship required to new RRs to maintain the Initial Trust Relationship required to
designate those RR(s) as Trust Anchor(s). designate those RRs as Trust Anchors.
Trust Anchor Maintenance: Any change in a validating security-aware Trust Anchor Maintenance: Any change in a validating security-aware
resolver to add a new Trust Anchor, delete an existing Trust resolver to add a new Trust Anchor, delete an existing Trust
Anchor, or replace an existing Trust Anchor with another. This Anchor, or replace an existing Trust Anchor with another. This
change might be accomplished manually or in some automated manner. change might be accomplished manually or in some automated manner.
Those responsible for operation of the security-aware resolver are Those responsible for operation of the security-aware resolver are
responsible for establishing policies and procedures to ensure responsible for establishing policies and procedures to ensure
that a sufficient Initial Trust Relationship is in place before that a sufficient Initial Trust Relationship is in place before
adding Trust Anchor(s) for a particular DNS zone to their adding Trust Anchors for a particular DNS zone to their security-
security-aware resolver configuration. aware resolver configuration.
Trust Anchor Revocation and Removal: The invalidation of a Trust Anchor Revocation and Removal: The invalidation of a
particular Trust Anchor that results when the operator of the particular Trust Anchor that results when the operator of the
signed zone revokes or removes a DNSKEY RR or DS RR that is being signed zone revokes or removes a DNSKEY RR or DS RR that is being
used as a Trust Anchor by any security-aware resolver(s). It is used as a Trust Anchor by any security-aware resolver. It is
possible that a zone administrator may invalidate more than one RR possible that a zone administrator may invalidate more than one RR
at one point in time, therefore, it MUST be clear to both the zone at one point in time, therefore, it MUST be clear to both the zone
administrator and security-aware resolver operator the exact RR(s) administrator and security-aware resolver the exact RR(s) that
that have been revoked or removed so the proper Trust Anchor or have been revoked or removed so the proper Trust Anchor or Trust
Trust Anchors are removed by the operators of the security-aware Anchors are removed.
resolver.
Trust Anchor Rollover: The method or methods necessary for the Trust Anchor Rollover: The method or methods necessary for the
secure replacement of one or multiple Trust Anchor(s) held by secure replacement of one or multiple Trust Anchors held by
security-aware resolvers. Trust Anchor Rollover should be security-aware resolvers. Trust Anchor Rollover should be
considered a sub-set of Trust Anchor Maintenance. considered a sub-set of Trust Anchor Maintenance.
Normal or Scheduled Trust Anchor Rollover: The operator of a DNSSEC Normal or Pre-Scheduled Trust Anchor Rollover: The operator of a
signed zone has issued new DNSKEY RR(s) and/or DS RR(s) as a part DNSSEC signed zone has issued new DNSKEY and/or DS RR(s) as a part
of an operational routine and may revoke existing DNSKEY RR(s) of an operational routine.
and/or DS RR(s) at some point in time.
Emergency Trust Anchor Rollover: The operator of a signed zone has Emergency or Non-Scheduled Trust Anchor Rollover: The operator of a
issued new DNSKEY RR(s) and/or DS RR(s) as part of an exceptional signed zone has issued new DNSKEY and/or DS RR(s) as part of an
event. exceptional event.
Emergency Trust Anchor Revocation: The operator of a signed zone Emergency Trust Anchor Revocation: The operator of a signed zone
wishes to indicate that the current DNSKEY and/or DS RR(s) are no wishes to indicate that the current DNSKEY and/or DS RR(s) are no
longer valid as part of an exceptional event. longer valid as part of an exceptional event.
5. Requirements 5 Requirements
Following are the requirements for DNSSEC automated specification- Following are the requirements for DNSSEC automated specification-
based Trust Anchor Rollover: based Trust Anchor Rollover:
5.1. Scalability 5.1 Scalability
The automated Trust Anchor Rollover solution MUST be capable of The automated Trust Anchor Rollover solution MUST be capable of
scaling to Internet-wide useage. scaling to Internet-wide useage. The probable largest number of
instances of security-aware resolvers needing to rollover a Trust
The probable largest number of instances of security-aware resolvers Anchor will be for the root zone. This number could be extremely
needing to rollover a Trust Anchor will be for the root zone. This large (possibly many millions) if a number of applications have
number could be extremely large (possibly many millions) if a number embedded security-aware resolvers.
of applications have embedded security-aware resolvers.
The automated Trust Anchor Rollover solution MUST be able to support The automated Trust Anchor Rollover solution MUST be able to support
Trust Anchors for multiple zones and multiple Trust Anchors for each Trust Anchors for multiple zones and multiple Trust Anchors for each
DNS zone. The number of Trust Anchors that might be configured into DNS zone. The number of Trust Anchors that might be configured into
any one validating security-aware resolver is not known with any one validating security-aware resolver is not known with
certainty at this time but in most cases will be less than 20 and certainty at this time; in most cases it will be less than 20 but it
never expected to be as high as one thousand. may even be as high as one thousand.
5.2. No Intellectual Property Encumbrance 5.2 No Intellectual Property Encumbrance
Because trust anchor rollover is considered "mandatory-to-implement", Because trust anchor rollover is likely to be "mandatory-to-
section 8 of [RFC3979] requires that the technology solution chosen implement", section 8 of [5] requires that the technology solution
must not be known to be encumbered or must be available under chosen must not be known to be encumbered or must be available under
royalty-free terms. royalty-free terms.
For this purpose, "royalty-free" is defined as follows: world wide, For this purpose, "royalty-free" is defined as follows: world wide,
irrevocable, perpetual right to use, without fee, in commerce or irrevocable, perpetual right to use, without fee, in commerce or
otherwise, where "use" includes descriptions of algorithms, otherwise, where "use" includes descriptions of algorithms,
distribution and/or use of hardware implementations, distribution distribution and/or use of hardware implementations, distribution
and/or use of software systems in source and/or binary form, in all and/or use of software systems in source and/or binary form, in all
DNS or DNSSEC applications including registry, registrar, domain name DNS or DNSSEC applications including registry, registrar, domain name
service including authority, recursion, caching, forwarding, stub service including authority, recursion, caching, forwarding, stub
resolver, or similar. resolver, or similar.
In summary, no implementor, distributor, or operator of the In summary, no implementor, distributor, or operator of the
technology chosen for trust anchor management shall be expected or technology chosen for trust anchor management shall be expected or
required to pay any fee to any IPR holder for the right to implement, required to pay any fee to any IPR holder for the right to implement,
distribute, or operate a system which includes the chosen mandatory- distribute, or operate a system which includes the chosen mandatory-
to-implement solution. to-implement solution.
5.3. General Applicability 5.3 General Applicability
The solution MUST provide the capability to maintain Trust Anchors in The solution MUST provide the capability to maintain Trust Anchors in
security-aware resolvers for any and all DNS zones. security-aware resolvers for any and all DNS zones.
5.4. Support Private Networks 5.4 Support Private Networks
The solution MUST support private networks with their own DNS The solution MUST support private networks with their own DNS
hierarchy. hierarchy.
5.5. Detection of Stale Trust Anchors 5.5 Detection of Stale Trust Anchors
The Trust Anchor Rollover solution MUST allow a validating security- The Trust Anchor Rollover solution MUST allow a validating security-
aware resolver to be able to detect if the DNSKEY or DS RR(s) can no aware resolver to be able to detect if the DNSKEY and/or DS RR(s) can
longer be updated given the current set of actual trust-anchors, so no longer be updated given the current set of actual trust-anchors.
that initial trust may be re-established. In these cases, the resolver should inform the operator of the need
to reestablish initial trust.
5.6. Manual Operations Permitted 5.6 Manual Operations Permitted
The operator of a security-aware resolver may choose manual or The operator of a security-aware resolver may choose manual or
automated rollover, but the rollover protocol must allow the automated rollover, but the rollover protocol must allow the
implementation to support both automated and manual rollover. implementation to support both automated and manual rollover.
Implementation of the rollover protocol is likely to be mandatory, Implementation of the rollover protocol is likely to be mandatory,
but that's out of scope for this requirements document. but that's out of scope for this requirements document.
5.7. Planned and Unplanned Rollovers 5.7 Planned and Unplanned Rollovers
The solution MUST permit both planned (pre-scheduled) and unplanned The solution MUST permit both planned (pre-scheduled) and unplanned
(non-scheduled) rollover of Trust Anchors. Support for providing an (non-scheduled) rollover of Trust Anchors. Support for providing an
Initial Trust Relationship is OPTIONAL. Initial Trust Relationship is OPTIONAL.
5.8. Timeliness 5.8 Timeliness
Resource Records used as Trust Anchors SHOULD be able to be Resource Records used as Trust Anchors SHOULD be able to be
distributed to security-aware resolvers in a timely manner. distributed to security-aware resolvers in a timely manner.
Operators of security-aware resolvers need to acquire new and remove Security-aware resolvers need to acquire new and remove revoked
revoked DNSKEY or DS RR(s) that are being used as Trust Anchors for a DNSKEY and/or DS RRs that are being used as Trust Anchors for a zone
zone such that no old RR is used as a Trust Anchor for long after the such that no old RR is used as a Trust Anchor for long after the zone
zone issues new or revokes existing RR(s). issues new or revokes existing RRs.
5.9. High Availability 5.9 High Availability
Information about the zone administrator's view of the state of Information about the zone administrator's view of the state of
Resource Records used as Trust Anchors SHOULD be available in a Resource Records used as Trust Anchors SHOULD be available in a
trustworthy manner at all times to security-aware resolvers. trustworthy manner at all times to security-aware resolvers.
Information about Resource Records that a zone administrator has Information about Resource Records that a zone administrator has
invalidated which are known to be used as Trust Anchors should be invalidated which are known to be used as Trust Anchors should be
available in a trustworthy manner for a reasonable length of time. available in a trustworthy manner for a reasonable length of time.
5.10. New RR Types 5.10 New RR Types
If a Trust Anchor Rollover solution requires new RR types or protocol If a Trust Anchor Rollover solution requires new RR types or protocol
modifications, this should be considered in the evaluation of modifications, this should be considered in the evaluation of
solutions. The Working Group needs to determine whether such changes solutions. The Working Group needs to determine whether such changes
are a good thing or a bad thing or something else. are a good thing or a bad thing or something else.
5.11. Support for Trust Anchor Maintenance Operations 5.11 Support for Trust Anchor Maintenance Operations
The Trust Anchor Rollover solution MUST support operations that allow The Trust Anchor Rollover solution MUST support operations that allow
a validating security-aware resolver to add a new Trust Anchor, a validating security-aware resolver to add a new Trust Anchor,
delete an existing Trust Anchor, or replace an existing Trust Anchor delete an existing Trust Anchor, or replace an existing Trust Anchor
with another. with another.
5.12. Recovery From Compromise 5.12 Recovery From Compromise
The Trust Anchor Rollover solution MUST allow a security aware The Trust Anchor Rollover solution MUST allow a security aware
resolver to be able to recover from the compromise of any of its resolver to be able to recover from the compromise of any of its
configured Trust Anchors for a zone so long as at least one other configured Trust Anchors for a zone so long as at least one other
key, which is known to have not been compromised, is configured as a key, which is known to have not been compromised, is configured as a
Trust Anchor for that same zone at that resolver. Trust Anchor for that same zone at that resolver.
5.13. Non-degrading Trust 5.13 Non-degrading Trust
The Trust Anchor Rollover solution MUST provide sufficient means to The Trust Anchor Rollover solution MUST provide sufficient means to
ensure authenticity and integrity so that by the existing trust ensure authenticity and integrity so that the existing trust relation
relation does not degrade by performing the rollover. does not degrade by performing the rollover.
6. Security Considerations 6 Security Considerations
This document defines overall requirements for an automated This document defines overall requirements for an automated
specification-based Trust Anchor Rollover solution for security-aware specification-based Trust Anchor Rollover solution for security-aware
resolvers but specifically does not define the security mechanisms resolvers but specifically does not define the security mechanisms
needed to meet these requirements. needed to meet these requirements.
7. IANA Considerations 7 IANA Considerations
This document has no actions for the IANA. This document has no actions for the IANA.
8. Acknowledgements 8 Acknowledgements
None at this point. This document reflects the majority opinion of the DNSEXT Working
Group members on the topic of requirements related to DNSSEC trust
anchor rollover. The contributions made by various members of the
working group to improve the readability and style of this document
are graciously acknowledged.
9. Normative References 9. Normative References
[1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033, "DNS Security Introduction and Requirements", RFC 4033,
March 2005. March 2005.
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034, "Resource Records for the DNS Security Extensions", RFC 4034,
March 2005. March 2005.
[4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions", "Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005. RFC 4035, March 2005.
[5] Bradner, S., "Intellectual Property Rights in IETF Technology",
RFC 3979, March 2005.
Authors' Addresses Authors' Addresses
Howard Eland Howard Eland
Afilias Limited Afilias Limited
300 Welsh Road 300 Welsh Road
Building 3, Suite 105 Building 3, Suite 105
Horsham, PA 19044 Horsham, PA 19044
USA USA
Email: heland@afilias.info Email: heland@afilias.info
 End of changes. 53 change blocks. 
128 lines changed or deleted 131 lines changed or added

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