draft-ietf-dnsext-zone-status-03.txt

bind-3.2.

DNSEXT WG                                                 Edward Lewis
INTERNET DRAFT                                                NAI Labs
Category:I-D                                        September 19, 2000

           DNS Security Extension Clarification on Zone Status
                 <draft-ietf-dnsext-zone-status-03.txt>

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

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.

Comments should be sent to the authors or the DNSEXT WG mailing list
[e-mail].

This draft expires on March, 19, 2001.

Copyright Notice

Copyright (C) The Internet Society (1999, 2000).  All rights reserved.

Abstract

The definition of a secured zone is presented, clarifying and updating
sections of RFC 2535. RFC 2535 defines a zone to be secured based on a
per algorithm basis, e.g., a zone can be secured with RSA keys, and
not secured with DSA keys.  This document changes this to define a
zone to be secured or not secured regardless of the key algorithm used
(or not used).  To further simplify the determination of a zone's
status, "experimentally secure" status is deprecated.

1 Introduction

Whether a DNS zone is "secured" or not is a question asked in at least
four contexts.  A zone administrator asks the question when
configuring a zone to use DNSSEC.  A dynamic update server asks the
question when an update request arrives, which may require DNSSEC
processing.  A delegating zone asks the question of a child zone when
the parent enters data indicating the status the child.  A resolver
asks the question upon receipt of data belonging to the zone.


Expires March 19, 2001                                      [Page  1]
Internet Draft                                     September 19, 2000

1.1 When a Zone's Status is Important

A zone administrator needs to be able to determine what steps are
needed to make the zone as secure as it can be.  Realizing that due to
the distributed nature of DNS and its administration, any single zone
is at the mercy of other zones when it comes to the appearance of
security.  This document will define what makes a zone qualify as
secure.

A name server performing dynamic updates needs to know whether a zone
being updated is to have signatures added to the updated data, NXT
records applied, and other required processing.  In this case, it is
conceivable that the name server is configured with the knowledge, but
being able to determine the status of a zone by examining the data is
a desirable alternative to configuration parameters.

A delegating zone is required to indicate whether a child zone is
secured.  The reason for this requirement lies in the way in which a
resolver makes its own determination about a zone (next paragraph). To
shorten a long story, a parent needs to know whether a child should be
considered secured.  This is a two part question.  Under what
circumstances does a parent consider a child zone to be secure, and
how does a parent know if the child conforms?

A resolver needs to know if a zone is secured when the resolver is
processing data from the zone.  Ultimately, a resolver needs to know
whether or not to expect a usable signature covering the data.  How
this determination is done is out of the scope of this document,
except that, in some cases, the resolver will need to contact the
parent of the zone to see if the parent states that the child is
secured.

1.2 Islands of Security

The goal of DNSSEC is to have each zone secured, from the root zone
and the top-level domains down the hierarchy to the leaf zones.
Transitioning from an unsecured DNS, as we have now, to a fully
secured - or "as much as will be secured" - tree will take some time.
During this time, DNSSEC will be applied in various locations in the
tree, not necessarily "top down."

For example, at a particular instant, the root zone and the "test."
TLD might be secured, but region1.test. might not be.  (For reference,
let's assume that region2.test. is secured.)  However,
subarea1.region1.test. may have gone through the process of becoming
secured, along with its delegations.  The dilemma here is that
subarea1 cannot get its zone keys properly signed as its parent zone,
region1, is not secured.

The colloquial phrase describing the collection of contiguous secured
zones at or below subarea1.region1.test. is an "island of security." 
The only way in which a DNSSEC resolver will come to trust any data
from this island is if the resolver is pre-configured with the zone
key(s) for subarea1.region1.test., i.e., the root of the island of

Expires March 19, 2001                                      [Page  2]
Internet Draft                                     September 19, 2000

security.  Other resolvers (not so configured) will recognize this
island as unsecured.

An island of security begins with one zone whose public key is
pre-configured in resolvers.  Within this island are subzones which
are also secured.  The "bottom" of the island is defined by
delegations to unsecured zones.  One island may also be on top of
another - meaning that there is at least one unsecured zone between
the bottom of the upper island and the root of the lower secured
island.

Although both subarea1.region1.test. and region2.test. have both been
properly brought to a secured state by the administering staff, only
the latter of the two is actually "globally" secured - in the sense
that all DNSSEC resolvers can and will verify its data.  The former,
subarea1, will be seen as secured by a subset of those resolvers, just
those appropriately configured.  This document refers to such zones as
being "locally" secured.

In RFC 2535, there is a provision for "certification authorities,"
entities that will sign public keys for zones such as subarea1.  There
is another draft, [SIGAUTH], that restricts this activity.  Regardless
of the other draft, resolvers would still need proper configuration to
be able to use the certification authority to verify the data for the
subarea1 island.

1.2.1 Determing the closest security root

Given a domain, in order to determine whether it is secure or not, the
first step is to determine the closest security root.  The closest
security root is the top of an island of security whose name has the
most matching (in order from the root) right-most labels to the given
domain.

For example, given a name "sub.domain.testing.signed.exp.test.", and
given the secure roots "exp.test.", "testing.signed.exp.test." and
"not-the-same.xy.", the middle one is the closest.  The first secure
root shares 2 labels, the middle 4, and the last 0.

The reason why the closest is desired is to eliminate false senses of
insecurity becuase of a NULL key.  Continuing with the example, the
reason both "testing..." and "exp.test." are listed as secure root is
presumably because "signed.exp.test." is unsecured (has a NULL key). 
If we started to descend from "exp.test." to our given domain
(sub...), we would encounter a NULL key and conclude that sub... was
unsigned.  However, if we descend from "testing..." and find keys
"domain...." then we can conclude that "sub..." is secured.

Note that this example assumes one-label deep zones, and assumes that
we do not configure overlapping islands of security.  To be clear, the
definition given should exclude "short.xy.test." from being a closest
security root for "short.xy." even though 2 labels match.

Overlapping islands of security introduce no conceptually interesting

Expires March 19, 2001                                      [Page  3]
Internet Draft                                     September 19, 2000

ideas and do not impact the protocol in anyway.  However, protocol
implementers are advised to make sure their code is not thrown for a
loop by overlaps.  Overlaps are sure to be configuration problems as
islands of security grow to encompass larger regions of the name
space.

1.3 Parent Statement of Child Security

In 1.1 of this document, there is the comment "the parent states that
the child is secured."  This has caused quite a bit of confusion.

The need to have the parent "state" the status of a child is derived
from the following observation.  If you are looking to see if an
answer is secured, that it comes from an "island of security" and is
properly signed, you must begin at the (appropriate) root of the
island of security.

To find the answer you are inspecting, you may have to descend through
zones within the island of security.  Beginning with the trusted root
of the island, you descend into the next zone down.  As you trust the
upper zone, you need to get data from it about the next zone down,
otherwise there is a vulnerable point in which a zone can be hijacked. 
When or if you reach a point of traversing from a secured zone to an
unsecured zone, you have left the island of security and should
conclude that the answer is unsecured.

However, in RFC 2535, section 2.3.4, these words seem to conflict with
the need to have the parent "state" something about a child:

   There MUST be a zone KEY RR, signed by its superzone, for every
   subzone if the superzone is secure. This will normally appear in
   the subzone and may also be included in the superzone.  But, in 
   the case of an unsecured subzone which can not or will not be
   modified to add any security RRs, a KEY declaring the subzone 
   to be unsecured MUST appear with the superzone signature in the
   superzone, if the superzone is secure.

The confusion here is that in RFC 2535, a secured parent states that a
child is secured by SAYING NOTHING ("may also be" as opposed to "MUST
also be").  This is counter intuitive, the fact that an absence of
data means something is "secured."  This notion, while acceptable in a
theoretic setting has met with some discomfort in an operation
setting.  However, the use of "silence" to state something does indeed
work in this case, so there hasn't been sufficient need demonstrated
to change the definition.

1.4 Impact on RFC 2535

This document updates sections of RFC 2535.  The definition of a
secured zone is an update to section 3.4 of the RFC.  Section 3.4 is
updated to eliminate the definition of experimental keys and
illustrate a way to still achieve the functionality they were designed
to provide.  Section 3.1.3 is updated by the specifying the value of
the protocol octet in a zone key.

Expires March 19, 2001                                      [Page  4]
Internet Draft                                     September 19, 2000

1.5 "MUST" and other key words

The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED",  and "MAY"
in this document are to be interpreted as described in [RFC 2119]. 
Currently, only "MUST" is used in this document.

2 Status of a Zone

In this section, rules governing a zone's DNSSEC status are presented.
There are three levels of security defined: global, local, and
unsecured.  A zone is globally secure when it complies with the
strictest set of DNSSEC processing rules.  A zone is locally secured
when it is configured in such a way that only resolvers that are
appropriately configured see the zone as secured.  All other zones are
unsecured.

Note: there currently is no document completely defining DNSSEC
verification rules.  For the purposes of this document, the strictest
rules are assumed to state that the verification chain of zone keys
parallels the delegation tree up to the root zone.  (See 2.b below.) 
This is not intended to disallow alternate verification paths, just to
establish a baseline definition.

To avoid repetition in the rules below, the following terms are
defined.

2.a. Zone signing KEY RR - A KEY RR whose flag field has the value 01
for name type (indicating a zone key) and either value 00 or value 01
for key type (indicating a key permitted to authenticate data).  (See