Internet DRAFT - draft-moreau-dnsext-tak-req
draft-moreau-dnsext-tak-req
INTERNET DRAFT Thierry Moreau
Document: draft-moreau-dnsext-tak-req-00.txt CONNOTECH
Category: Informational February, 2006
Expires: August, 2006
DNSKEY Trust Anchor Key Requirements
Status of this Memo
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2006).
IPR Disclosure Acknowledgment
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.
Abstract
This draft attempts to fill a portion of the gap between DNSSEC
deployment expectations and the lack of DNSSEC trust anchor key
management solutions, protocol and procedural aspects. Specific
requirements are stated at a level of abstraction that should
accommodate solution alternatives to the issues of providing trust
anchor keys to DNSSEC-aware resolvers, and rolling those keys.
Nonetheless, the characteristics the DNSSEC protocols and the DNS
operation contingencies do shape many of the requirements.
Moreau Informational [page 1]
Internet-Draft DNSSEC Trust Anchor Key Requirements February, 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Trust Anchor Key Life Cycle Requirements . . . . . . . . . . . . . 3
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Resolver-Side Trust Anchor Key Life Cycle . . . . . . . . . 4
2.3 Nameserver-Side Trust Anchor Key Life Cycle . . . . . . . . 6
3. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 DNS and DNSSEC Protocol Hosting . . . . . . . . . . . . . . 8
3.2 Deployment Agility . . . . . . . . . . . . . . . . . . . . . 8
3.3 Suitable Documentation . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Normative References . . . . . . . . . . . . . . . . . . . . . . . 9
6. Informative References . . . . . . . . . . . . . . . . . . . . . . 9
Annex A - Overview of DNSSEC Incremental Burden for Zone Managers . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 10
IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property . . . . . . . . . . . . . . . . . . . . . 11
Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . 11
Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
In the operation of the DNSSEC protocols ([RFC4033], [RFC4034],
[RFC4035]), the presence of at least one trust anchor key in a
DNSSEC-aware resolver is a condition for the delivery of effective
security services to applications. A trust anchor key is useful for
DNSSEC "islands of security" and the root zone if and when it
becomes DNSSEC-aware. To date, the IETF approach to the trust
anchor key management issues has been to leave them out of scope of
RFCs, perhaps due to the administrative aspects of DNS resolver
trust configuration.
As the DNSSEC protocols are expected to go out of the lab into the
field, it is perhaps useful to formalize at least some aspects of
the trust anchor key management. The need to roll (i.e. renew)
DNSSEC signature keys applies to trust anchor keys like other types
of cryptographic keys. Thus, a protocol interoperability question
arises if an in-band, automated trust anchor key rollover mechanism
is desirable.
The present informational document states trust anchor key
requirements in the context of DNSSEC deployment, assuming further
Moreau Informational [page 2]
Internet-Draft DNSSEC Trust Anchor Key Requirements February, 2006
standardization activities might turn these requirements into
protocol and operational specifications. We whish our contribution
to be closely related to the specifics of the DNSSEC application
environment for the public key cryptography digital signature
technology, e.g. not repeating general guidelines on cryptographic
key life cycle management ([SP800-57-1]).
DNS zone managers incur an incremental administrative burden when
operating DNSSEC-aware nameservers and associated DNS registry
functions. Trust anchor key requirements contribute to this
incremental burden. In order to position the impact of trust anchor
key on the overall DNSSEC workload, the latter is described in the
informative annex A.
2. Trust Anchor Key Life Cycle Requirements
2.1 Overview
In security protocols, a bird's eye view of exchanges is usually
misleading since a given participant in an instance of the protocol
experiences a sequence of events which may or may not comply to the
bird's eye view, with only local significance. The same applies to
the case of DNSSEC trust anchor key management, but with a strong
asymmetry between a small number of nameservers and a huge number
of resolvers, a unidirectional information flow (i.e. DNS query
packets convey no state information to nameservers), and local
determination by individual resolvers of public signature key
trustworthiness.
Thus, the system-wide or bird's eye view a DNSSEC trust anchor key
life cycle is a unidirectional flow of data and trust bases, i.e.
a) the performance of security procedures by zone managers,
b) the partial reflection of this performance in DNS data
broadcasted by authoritative nameservers, and
c) a local determination of trust anchor key status by resolvers
exposed to this broadcasted DNS data (or a portion of it).
A DNSSEC trust anchor key is the public signature key associated
with a DNS domain name, i.e. having a private key counterpart
allegedly controlled by an organization authorized to publish DNS
data for this domain name. The first basis of trust is a belief
that the controlling organization will adhere to the generally
agreed security principles for digital signatures by central
organizations.
************ vvvvvvvvvvvvvvvvvvvv ************
Thus, a first requirement is the adoption of documented trust
anchor key management procedures and protocols by the entity
identified in the whois information for the root zone or an island
of trust.
************ ==================== ************
Moreau Informational [page 3]
Internet-Draft DNSSEC Trust Anchor Key Requirements February, 2006
2.2 Resolver-Side Trust Anchor Key Life Cycle
For a DNS resolver, a trust anchor key implies a sense of assurance
that a given public key is the legitimate one for a DNS zone name.
A "sense of assurance" has obviously no direct digital
representation. In a DNS resolver system, a trusted configuration
space is needed to store trust anchor key information so that the
DNS resolver can keep the status of trusted keys on behalf of the
users. Although this is not a requirement for the key management
scheme itself, it appears significant.
************ vvvvvvvvvvvvvvvvvvvv ************
The DNS resolver system support for trust anchor key management
must include some form of local trusted configuration store.
************ ==================== ************
Cryptographic techniques, notably digital signatures, merely
translate trust (or "sense of assurance") about a piece of data
into trustworthiness about other data. The current DNSSEC
specifications precisely define a trust anchor key as the public
key at the end of a digital signature chain, i.e. a chain of trust
translations. Accordingly, a trust anchor key inherits its
trustworthiness either from "out-of-band" mechanisms or from
recourse to cryptographic techniques that go beyond the current
DNSSEC use of digital signatures.
In practice, out-of-band trust anchor configuration is likely to
occur with the installation of DNS resolver software from a
trustworthy supplier or provisioning process, perhaps with
procedural refinements for greater integrity assurance. Such
opportunity for clean-out-of-the-box integrity assurance is deemed
to be very rare later in a trust anchor life cycle.
************ vvvvvvvvvvvvvvvvvvvv ************
A trust anchor key management scheme may assume an opportunity for
initializing a trusted configuration in a DNS resolver system at
the very beginning of key life cycle for a given DNS resolver
instance.
************ ==================== ************
By essence, trust is a lasting abstraction. When implemented as a
digital signature public key configuration entry, the duration
property contradicts the generally agreed recommendation to roll
keys according to a schedule (cryptoperiod). For the record, here
are the rationales for rolling keys in the first place:
o cryptographic strength concerns, i.e. an old key might be
cracked,
o security operations concerns, i.e. over time, the
uninterrupted confidentiality a production private key becomes
less trustworthy,
o survivability concerns to the extent that a scheduled renewal
operation is like a rehearsal for an emergency private key
recovery, or an alternative for it (e.g. if the private key
Moreau Informational [page 4]
Internet-Draft DNSSEC Trust Anchor Key Requirements February, 2006
breach has no practical impact or it is merely suspected).
The conflicting goals of lasting trust and periodic rollover
recommendation are compounded by the very limited feasibility of
repeated out-of-band procedures and the huge number of DNS
resolvers. This leads to an important requirement for trust anchor
key management, paving the way to creative application of
cryptographic mechanisms (i.e. beyond the current DNSSEC use of
digital signatures) for the rollover operation at the resolver
side.
************ vvvvvvvvvvvvvvvvvvvv ************
A trust anchor key management scheme must specify a trust anchor
rollover operation that is automated to the greatest possible
extent at the DNS resolver side. A rollover operation must allow a
DNS resolver to obtain a new DNSSEC public signature key for the
root zone or an island of trust, with cryptographic assurance of
trustworthiness equivalent to the trustworthiness of the preceding
public signature key for the same zone when this last key was first
obtained by the DNS resolver (or could have been obtained). A
rollover operation need not succeed at every attempt.
************ ==================== ************
The above requirement attempts to fit the real-world challenges of
DNSSEC deployment, but it relies on cryptography ("with
cryptographic assurance of") where it was previously stated that a
trust anchor key is at the end of a chain of recursive reuse of
cryptography. This must be acknowledged in a requirements
statement.
************ vvvvvvvvvvvvvvvvvvvv ************
The "catastrophic failure mode" of trust anchor key operation
specification is defined as the circumstances leading to, and
consequences of, a failure of any of the cryptographic mechanisms
relied upon for the rollover operation. A trust anchor key
management scheme must disclose the details of its catastrophic
failure mode.
************ ==================== ************
The above implicitly makes recovery from a catastrophic failure
event a non-requirement. This complies with the view that a trust
anchor key management solution for DNSSEC is merely an improvement
over long-lasting trust anchors (i.e. no rollover) or an human-
assisted rollover mechanism that is deemed to be error-prone with
the vast majority of end-users.
Up to now, emergency rollovers and key retirement were not
addressed. It is a non-requirement for a DNS resolver to
distinguish between an emergency rollover and a scheduled rollover:
there would be no use of an emergency rollover signaling in a DNS
resolver. Note that the above rollover operation requirement is
stated with the assumption that a key is not breached when it is
first made available to DNS resolvers. There is some level of
abstraction in the requirement statements which should be lowered
Moreau Informational [page 5]
Internet-Draft DNSSEC Trust Anchor Key Requirements February, 2006
by actual scheme proposals.
About key retirement, a DNS resolver is not in a position to
systematically receive a notice of trust anchor key retirement when
it occurs. However, if a DNS resolver detects that a trust anchor
key has been retired, it should protect itself against key reuse
attacks.
************ vvvvvvvvvvvvvvvvvvvv ************
If a trust anchor key management scheme allows a DNS resolver to
detect that a trust anchor key has been retired, a compliant
implementation of this scheme by a resolver must keep track of such
key retirement events and protect itself against public key reuse
attacks.
************ ==================== ************
2.3 Nameserver-Side Trust Anchor Key Life Cycle
On the nameserver side, the trust anchor key life cycle is
controlled by the DNS zone manager organization which asserts the
bind between the DNSSEC digital signature key and the zone name.
This same self-assertion occurs for secure zones with a secure
parent zone, but this time with a single receiving entity for the
assertion (i.e. the parent zone manager) instead of the whole
population of DNS resolvers.
A first question arises in the event of a change in the zone
manager controlling entity. If such a change occurs on a mutually
agreed basis and a collaborative mode of operation, it should be
transparent to third parties. In other cases, a disruptive change
occurs in the zone manager controlling entity, so that any
cryptographic key material used for DNSSEC, including for the
support of a trust anchor key management scheme, is either lost,
compromised, or suspect. For the root zone or an island of trust,
it is a non-requirement to support such disruptive changes in the
zone manager controlling entity.
Many other aspects of a digital signature key life cycle for a
signatory are applicable to the trust anchor key for a DNS zone
manager. Some guidelines in this area may be reflected in the vital
characteristics or features of a trust anchor key management
scheme, e.g. if they are part of the definition for the scheme's
"catastrophic failure mode" or if they provide data for the initial
trust configuration in DNS resolvers.
A digital signature key life cycle starts with the key pair
generation and goes through the states depicted in the diagram
below.
Moreau Informational [page 6]
Internet-Draft DNSSEC Trust Anchor Key Requirements February, 2006
key pair generation
-------------------
| |
| V
| dormant state
| =============
| |
V V
operational phase
=================
| |
| V
| breached state
| ==============
| |
V V
retired state
=============
It was mentioned that the opportunity to distribute out-of-band
trusted information to DNS resolvers is limited in practice to the
resolver installation time. This leads to a matching requirement
for the nameserver side:
************ vvvvvvvvvvvvvvvvvvvv ************
A trust anchor key management scheme must disclose to which extent
it is dependent on initial out-of-band distribution of trusted
configuration material from a zone manager to DNS resolvers.
************ ==================== ************
We can now state a few more requirements for trust anchor key
management scheme. These are derived from a general understanding
of the security issues in a signature key life cycle.
************ vvvvvvvvvvvvvvvvvvvv ************
A trust anchor key management scheme must allow the operational
phase of a trust anchor key to begin before the retired state of a
preceding trust anchor key.
************ ==================== ************
************ vvvvvvvvvvvvvvvvvvvv ************
A trust anchor key management scheme must include provisions
allowing a DNS zone manager to retire a trust anchor key in a way
that allows DNS resolvers to notice the key retirement.
************ ==================== ************
Note that the above requirement is partially a wishful thinking
requirement since it does not state any guideline on the likelihood
or ease with which DNS resolvers would notice key retirement.
************ vvvvvvvvvvvvvvvvvvvv ************
The DNS zone manager should make prudent application of generally
agreed security principles throughout the DNSSEC digital signature
Moreau Informational [page 7]
Internet-Draft DNSSEC Trust Anchor Key Requirements February, 2006
key life cycle. A trust anchor key management scheme must disclose
which aspects of these security principles are needed for the
avoidance of the scheme's critical failure mode.
************ ==================== ************
3. Other Issues
3.1 DNS and DNSSEC Protocol Hosting
A DNSSEC trust anchor key management scheme should adhere to the
design principles and detailed protocol specifications of the DNS
and DNSSEC protocols. The assessment of a scheme's compliance to
this recommendation is a matter of public review, ease of
integration into existing DNS and DNSSEC tools and servers, and
quality of supporting documentation.
The performance impact of a scheme falls into this general
recommendation. Ideally, the DNS resolver procedures should
restrict the occurrence of trust-anchor-key-specific queries to
circumstances where a change in a trust anchor key status is likely
to occur. For DNS answer sizes, the scheme's impact should be
estimated notable for incremental response sizes for queries not
directly related to trust anchor key management.
3.2 Deployment Agility
The DNSSEC deployment can not occur at once for the whole Internet.
Islands of trust are deemed to appear while parent zones are not
yet secured and ready to accept secure delegations. This implies a
need for graceful transition from an island of trust to a secure
zone with a secure parent. During this transition, some DNS
resolvers might view the zone still as an island of security, while
others would be unaware that the zone was ever an island of
security.
Also, it was mentioned that a DNS zone manager may revert to a
DNSSEC-oblivious mode of operation after the zone has been made
DNSSEC-aware. This course of action is possible for the parent zone
of an ordinary secured zone. This opens the door to a normal
secured zone becoming an island of security following a decision
made by a third party. So the graceful transition in the reverse
direction from the preceding paragraph should be supported as well
by a trust anchor key management scheme.
Specific requirements in the area of DNSSEC deployment agility
might be stated if a formal DNSSEC deployment roadmap is brought
up. Other issues of deployment agility may address the concurrent
existence of multiple trust anchor key management schemes for a
given zone, or the presence of private trust arrangements in the
public DNS, neither of which should be prevented by a particular
scheme.
Moreau Informational [page 8]
Internet-Draft DNSSEC Trust Anchor Key Requirements February, 2006
3.3 Suitable Documentation
Documentation guidelines may be developed. For instance, a mandated
documentation of cryptoperiod management facilities built in a
scheme may be deserved despite the absence of requirements
expressed as a cryptoperiod implementation issue (indirectly
provided by the required ability to retire a key and the required
overlap between the operational phases of keys).
4. Security Considerations
The present document is wholly about security, but incompletely
describes the security downgrade caused by the DNS protocol
environment, e.g. the inability for a zone manager to send a
specific message to DNS resolvers. Specifications derived from the
present document should be throughly reviewed for a clear statement
of security goals and limitations.
5. Normative References
[RFC4033] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, "DNS
Security Introduction and Requirements", RFC 4033, March 2005
[RFC4034] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005
[RFC4035] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005
6. Informative Reference
[SP800-57-1] Elaine Barker, William Barker, William Burr, William
Polk, and Miles Smid, "Recommendation for Key Management
- Part 1: General", NIST Special Publication 800-57 part
1, August, 2005
Moreau Informational [page 9]
Internet-Draft DNSSEC Trust Anchor Key Requirements February, 2006
Annex A - Overview of DNSSEC Incremental Burden for Zone Managers
This annex gives a brief overview of the DNSSEC incremental burden
for zone managers. It is intended to prevent a magnifying glass
effect that could taint the trust anchor key management as "the"
show stopper for DNSSEC deployment. In fact, once the open
questions raised in the body of the present document are answered,
the zone manager procedures for trust anchor key management should
be a small portion of the overall DNSSEC incremental burden.
Ensuring stable operations of authoritative nameservers.
DNSSEC incremental burden:
o monitoring the performance impact of DNSSEC deployment,
o revision of arrangements for secondary nameserver
operations,
o possible DNS software upgrade for continued DNSSEC
compliance.
Maintaining accurate records in zone file contents, and whois
information.
DNSSEC incremental burden:
o revision of procedures for authenticating change
requests,
o for secure delegations, use of secure provisioning tools,
o implementing zone file signature procedures with adequate
controls of DNSSEC private signature keys.
For zones other than the root zone (and other than islands of trust
once DNSSEC is deployed), the DNS zone name registration with the
parent must be maintained.
DNSSEC incremental burden:
o use the secure provisioning tools implemented by the
parent zone for maintaining the parental DS delegation.
Finally, for the root zone and islands of trust, the DNSSEC
incremental burden includes the procedures for trust anchor key
management to be developed from the requirements stated in the body
of this document.
Author's Address
Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc, Canada
Tel.: +1-514-385-5691
e-mail: thierry.moreau@connotech.com
Moreau Informational [page 10]
Internet-Draft DNSSEC Trust Anchor Key Requirements February, 2006
IPR Notices
Intellectual Property
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 ISOC's procedures with respect to rights in ISOC
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.
Copyright Notice
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.
Disclaimer
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.
Moreau Informational [page 11]
