Subject: Re: comments on draft-ietf-dnsext-zone-status-00.txt

From: Edward Lewis <[email-masked]>
Date: Mon, 27 Mar 2000 13:39:40 -0500

At 7:39 AM -0500 3/27/00, Donald E. Eastlake 3rd wrote:

First - regarding the importance of a resolver's configuration in the
judgement of whether a zone is perceived to be secure or not:  This
discussion is explicitly off-limits with regard to this document.  See the
penultimate paragraph of the Introduction.

>RFC 2535 specifically provides that being a zone KEY overrides the
>protocol field and thus there is no need to check the protocol field
>for a zone KEY (section 3.1.3) so this should be flagged as a change
>although I don't actually see any reason for this change.  The purpose
>of zone KEYs is to sign DNS data.  The protocol field is intended for
>use in connection with end-entity and user KEYs.

This section will then be marked as updating 2535.

>Seems like you need to make an exception for root.

As there is neither documentation on, nor a BCP de jure for, the method for
securing the root, hence I can't state the exception.  I will defer
addressing this until later.

>I would number the two sentences or put "Or" between them...

I will consider doing that.

>	In RFC 2535, a parent is required to hold a NULL key for an unsigned
>	child (a bone of contention here is how this works in light of
...
>
>As I have said several times before, the first sentence above is
>WRONG, was WRONG, and continues to be WRONG.  There is absolutely no
>problem under RFC 2535 in an insecure child and only that insecure
>child holding the NULL key signed by its parent.

RFC 2535, section 2.3.4, second paragraph, second sentence reads:
# 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.

What does the second sentence or your comment mean?

>	3.2.d. The parent MUST allow the child, through some trusted, probably
>	non-DNS mechanism, to request that the indication of the KEY set in
>	the NXT be turned off.  This allows a child to revert to an unsigned
>	state.
...
>not want to permit the child to become insecure.  Mandating the
>CAPABILITY, however, is quite reasonable.  Should say something like
>"The parent MUST have the capability of allowing the child....".

I'll make a change here.

>	The next issue is the means in which a validation action is reported
>	to the active zone.  On the surface, dynamically updating the NXT
>	would seem to make sense, but updating the NXT in this manner can lead
>	to a race condition in the server, this is unstable.  The issue here
...
>
>Could you say a bit more about the particular race condition you see?

I have labels x,y,z.  x has an A record and wants to add a TXT record.  x
begins with a "NXT y A NXT" entry.  I want this to become "NXT y A TXT
NXT."  While I request this change, it is possible that y is being
eliminated, so the NXT of x should point to z, not y.  The race condition
is what happens to the NXT of x.

>	7 Security Considerations
...
>If the resolver is "misbehaving", aren't all bets off?  With a well
>behaving resolver staticly configured with a good root key, there
>should be no way to dupe it into believing bad data...

Ergo, a misbehaving resolver is a security concern, which is why this is
mentioned here.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"Trying is the first step to failure." - Homer Simpson
"No! Try not. Do... or do not. There is no try." - Yoda
"It takes years of training to know when to do nothing" - Dogbert 1/21/00

Opinions expressed are property of my evil twin, not my employer.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Mon, 27 Mar 2000 07:39:57 -0500

A few comments...

	DNSEXT WG                                           Edward Lewis
	INTERNET DRAFT                                      NAI Labs
	Category:I-D                                        Feburary 1, 2000

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

	Status of this Memo

	...

	Abstract

	The definition of a secured zone is presented, updating RFC 2535.  The
	new definition has consequences which alter the interpretation of the
	NXT record, obsolete NULL keys, and the designation of "experimentally
	secure."

	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.

This distinction of four points of view is useful and I comment more
on each below.  But I think the last one, whether a particular
resolver in a particular case cares about whether it gets a SIG on
some data, is the most 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 (absent interaction with other zones).

Well, zones are always at the mercy of their ancestors (parent,
grandparent, etc.) for those retrieving data from the zone by working
their way down the DNS tree.  Whether a zone appears to be secure to a
particular resolver may also depend on the static key configuration of
and algorithms implemented at that resolver.

	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.

Given that under "simple dynamic update", which I expect to be
adopted, everything about update has to be explicitly configured in a
proprietary fashion at the primary server, having to configure whether
it needs to do SIG and NXT updates seems pretty trivial.  You have to
staticly configure on line private key(s) for the update in any case
and just doing the SIG and NXT update if there are any private keys
present and not if there aren't (since you can't in that case anyway)
seems adequate.  But I suppose you could look into the zone and see if
the SOA and/or apex KEY RRSET or whatever are signed if you want...

	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, what does a parent
	consider a secure child to be, and how does a parent know if the child
	conforms?

There may be little operational connections between a parent and a
child.  I don't think the standard should impose any obligation on the
parent to actually know what child operations "conform" to.  A secure
parent can only depend on information it has authoritatively received
from the child's management, i.e., KEY(s) to sign, or the like.  Just
how this authoritative communicaiton occures is an interesting
question outside the scope of this document, but parents already have
to authoritatively receive NS information from children.  See further
discussion below.

	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.

	This document updates several sections of RFC 2535.  The definition of
	a secured zone is an update to section 3.4 of the RFC.  The document
	updates section 2.3.4, by specifying a replacement for the NULL zone
	keys.  The document also updates section 3.4 to eliminate the
	definition of experimental keys and illustrate a way to still achieve
	the functionality they were designed to provide.

	2 Status of a Zone

	In this section, rules governing a zone's DNSSEC status are presented.
	There are three levels of security defined; full, private, and
	unsecured.  A zone is fully secure when it complies with the strictest
	set of DNSSEC processing rules.  A zone is privately 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.

It is always true that only resolvers that are appropriately
configured see a zone as secure.  For example, a resolver not staticly
configured with any key must consider all of DNS "inscure" and do resolution
the way it is currently done by security ignorant resolvers.  A resolver
configured only with a static key or keys for, say, co.jp. should look for
signatures there and can determine, from its point of view, whether
data below co.jp. is cryptographically verifiable but all the rest of
the DNS is "insecure" as above (unless, for some bizarre reason, parts
of the rest of DNS are signed by a co.jp key the resolver knows and
the resolvers policies allow such "cross certification").

	Note: there currently is no other document completely defining DNSSEC
	processing 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.  This is not
	intended to disallow alternate verification paths, just to establish a
	baseline definition.

	To avoid repetition in the rules below, the following term is 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
	RFC 2535, section 3.1.2).  The KEY RR also has a protocol octet value
	of DNSSEC (3) or All (255).

	2.1 Fully Secured

I don't like the term "Fully" here.  Sure, zones that use only
mandatory to implement algorithms and are lucky enough to have a
secure parent that will sign their keys are more likely to have
signatures be expected and be checked by a resolver in the general
case.  But it seems odd to call them "fully secure" when it is
possible that, due to static key configuration problems, there are
zero resolves that will end up applying cryptographic checks to their
content.  Similarly, it seems odd to refuse to call a zone "fully
secure" when every resolver that will ever retrieve from it will
expect signatures and try to verify them.  (Example of the later case
would be a zone internal to some company where the algorithm(s) used
in the zone and its zone KEY are staticly configures into all the
resolvers that will ever send queries to that zone.)

	A fully secured zone, in a nutshell, is a zone that uses only
	mandatory to implement algorithms (RFC 2535, section 3.2) and relies
	on a key certification chain that parallels the delegation tree. Fully
	secured zones are defined by the following rules.

	2.1.a. The zone's apex MUST have a KEY RR set.  There MUST be at least
	one zone signing KEY RR (2.a) of a mandatory to implement algorithm in
	the set.

	2.1.b. The zone's apex KEY RR set MUST be signed by a private key
	belonging to the parent zone.  The private key's public companion MUST
	be a zone signing KEY RR (2.a) of a mandatory to implement algorithm
	and owned by the parent's apex.

	If a zone cannot get a conforming signature from the parent zone, the
	child zone cannot be considered fully secured.

	2.1.c. NXT records MUST be deployed throughout the zone. (Updates RFC
	2535, section 2.3.2.)  Note: there is some operational discomfort with
	the current NXT record.  This requirement is open to modification when
	two things happen.  First, an alternate mechanism to the NXT is
	defined and second, a means by which a zone can indicate that it is
	using an alternate method.

That there are problems with NXT has been known for quite a while.
But whenever I bring up the possibility of change there is great
wailing that any changes will "delay deployment"...

	2.1.d. Each RR set that qualifies for zone membership MUST be signed
	by a key that is in the apex's KEY RR set and is a zone signing KEY RR
	(2.a) of a mandatory to implement algorithm.  (Updates 2535, section
	2.3.1.)

	2.2 Privately Secured

	A privately secured zone is a zone that complies with rules like those
	for fully secured, with the following exceptions.  The signing keys
	may be of an algorithm that is not mandatory to implement and/or the
	verification of the zone keys in use may rely on a verification chain
	that is not parallel to the delegation tree.

	2.2.a. The zone's apex MUST have a KEY RR set.  There MUST be at least
	one zone signing KEY RR (2.a) in the set.

	2.2.b. The zone's apex KEY RR set MUST be signed by a private key and
	one of the following two sentences MUST hold true.  The private key's
	public companion MUST be preconfigured in all the resolvers of
	interest.  The private key's public component MUST be a zone signing
	KEY RR (2.a) authorized to provide validation of the zone's apex KEY
	RR set, as recognized by resolvers of interest.

	The previous sentence is trying to convey the notion of using a
	trusted third party to provide validation of keys.  If the domain name
	owning the validating key is not the parent zone, the domain name must
	represent someone the resolver trusts to provide validation.

In general, I would think that the mechanism of such trust would be
via the static configuration of the public key.  That's why section
6.3 of RFC 2535 has optional Rule 3 to allow such limited cross
certification.

	2.2.c. NXT records MUST be deployed throughout the zone. (Updates RFC
	2535, section 2.3.2.) Note: see the discussion following 2.1.c.

	2.2.d. Each RR set that qualifies for zone membership MUST be signed
	by a key that is in the apex's KEY RR set and is a zone signing KEY RR
	(2.a).  (Updates 2535, section 2.3.1.)

	2.3 Unsecured

	All other zones qualify as unsecured.  This includes zones that are
	designed to be experimentally secure, as defined in a later section on
	that topic.

	2.4 Wrap up

	The designation of fully secured, privately secured, and unsecured are
	merely labels to apply to zones, based on their contents.  Resolvers,
	when determining whether a signature is expected or not, will only see
	a zone as secured or unsecured.

I think better terms would be "generally signed" and "specially
signed".  If .com is signed with a mandatory to implement algorithm
but root isn't signed at all and the public key for .com is widely
distributed and staticly configured in zillions of browsers, does it
make sense to say that .com is only "privately" secure?

	Resolvers that follow the most restrictive DNSSEC verification rules
	will only see fully secured zones as secured, and all others as
	unsecured, including zones which are privately secured.  Resolvers
	which are not as restrictive, such as those that implement algorithms
	in addition to the mandatory to implement algorithms, will see some
	privately secured zones as secured.

I hope few browsers follow the first sentence in the paragraph above.
For them, and assuming a change so that root can be "fully secured"
without having a parent, it would require everything from root down to
a zone for a resolver as you describe to consider that zone as secure.
But I believe that resolvers should consider any zone for which they
have staticly configured zone KEY(s) to be secure and to expect
signatures from them and check those signatures, even if the zone is,
say, dma.isg.mot.com and none of its ancesotrs are signed.

	The intent of the labels "fully" and "privately" is to identify the
	specific attributes of a zone.  The words are chosen to assist in the
	writing of a document recommending the actions a zone administrator
	take in making use of the DNS security extensions.  The words are
	explicitly not intended to convey a state of compliance with DNS
	security standards.

I think the terms "generally signed" and "specially signed" would be
better to describe these two types of zones.

	3 Parental Notification

	For a resolver to come to a definitive answer concerning a zone's
	security status, there is a requirement that the parent of a zone
	signify whether the child zone is signed or not.  The justification of
	this requirement requires a discussion of the resolver's activity,
	which is described in RFC 2535.

Note exception for root.  I think the better way to look at it is that
any zone for which a resolver has one or more zone KEY RR(s) staticly
configures is secure from the point of view of that resolver.  In
determining whether the descendents of such a zone are secure, the
resolver, naturally, would only want to depend on data which it had
cryptographically verified.

	In RFC 2535, a parent is required to hold a NULL key for an unsigned
	child (a bone of contention here is how this works in light of
	multiple algorithms).  The parent has the option to hold the keys of
	the child if the child is signed. The parent may also hold nothing
	cryptographic if the child is signed.  This, of course, assumes the
	parent is a signed zone.

There is some special language in RFC 2535 about this because of the
following problem: I expect that initially only a small subset of
zones will be signed.  And the administrators of unsigned zones will
not all be with it enough to get and insert a parent signed NULL key
in their zone.  If there isn't an indication of their security
somewhere, a resolver who is treating their parent as secure must, in
effect, deny access to this child (unless a request specifies that
checking is disabled).  If it knew the child was secure, via one or
more parent signed non-NULL zone keys for the child, it would be
expecting and checking for signatures in the child zone.  If it knew
that the child was insecure, due to a parent signed NULL key under RFC
2535, no matter where it found that parent signed NULL key, it would
know to just do traditional DNS resolution and not look for or try to
validate signatures in the zone.  If it can't find either indication,
it's stuck.  Note, in particular, that an adversary could have blocked
the transmission to the resolver of a parent signed non-NULL key so it
is unsafe to assume the child is insecure.

If DNS was being started from scratch with security, you could
reasonably expcect children to know they should be serving up security
status information about themselves.  But even assuming a much
stronger effort to deploy DNSSEC than I have seen, it will be years
before it would be reasonable to assume the cooperation of all
children.

In order to avoid denial of service to clueless children, RFC 2535
says parents MUST SUPPORT a NULL for an insecure child to be served
from them but it does NOT REQUIRE such a NULL to be served by the
parent if the child is willing to do it.  Let me repeat, RFC 2535 says
parents MUST SUPPORT a NULL for an insecure child to be served from
then but it does NOT REQUIRE that such a NULL be so server.  I am not
sue why I have been having such extraordinary difficulty getting this
point through.

	There is a strong case for discouraging a parent from holding keys of
	a signed child.  These include concrete concerns about performance and
	more abstract concerns about the liability of the parent.

Sure, it generally works better for the keys with parent signature to
be served from the child.  In the case of bloatzones like .com, it may
be impractical to serve them all from the parent.  But there isn't any
significant liability problem with the parent serving signed child
keys.  There are plenty of potential liability problems with being a
parent.  These probably increase when the parent signs the keys.
Before signing, the liability was just for the data being dynamically
served which can be corrected very quickly and in centralized.  At
least the primary is the most important, secondaries are also quite
important, but they the time you get to various caches floating around
out there, you usually don't have any clear way to prove the data came
from the authentic server. The more layers the data has gone through,
the fuzzier responsibilty is.  Signed data is very different.  No
matter whether retrieved directly from the primary or from a secondary
or from a child or from a random cache or even if found printed out on
a scrap of paper in the gutter somewhere, the server signature imposes
much clearer and more directly traceable responsibilty back to that
server which does not become fuzzier no matter how many times the data
is copied or passed around.  It is not significant whether the parent
serves the KEY and SIG itself.  Its repsonsibility and traceability
comes from the signature, not from serving the data to the world.
There is no significant liability effect from the parents decision as
to whether it will server up signed child keys.

	DNS [RFC 1034 and 1035] requires a parent to hold NS records for a
	child zone, this signifies the delegation.  RFC 2535 requires a
	secured parent to also have signed NXT records for the child, and
	possibly a signed KEY RR set (required for NULL key situations).

Being able to authenticatably deny the existence of a name using NXT
requires an NXT for every name in the zone, including the names of
children.  RFC 2535 does NOT require that the parent hold a signed
NULL key for insecure children.  It does require that a parent by able
to hold such a key in the case of cluelessly administered children to
avoid denial of DNS service to such clueless children by secure DNS
resolvers.  See remarks above concerning this.

	By redefining the security status of a zone to be per zone and not per
	algorithm, there is an opportunity to completely remove the need for a
	KEY RR set in the parent.  Because the question of whether the zone is
	secure or not is a yes-or-no question, the notification needs just one
	bit to be expressed.

As I said in previous mail, I think the change from per algorithm to
per zone security status is a good thing.  Of course "secure" depends
on your point of view.  A parent considering a zone "secure" if it has
signed keys for it is reasonable.  But a security aware resolver that
does not implement any of the algorithm(s) with which the zone is
signed should consider it insecure and do traditional non-secure
resolution in it.

	Keep in mind that the following sections speak to the contents of a
	zone, not a name server.  In the case of a name server speaking
	authoritatively for both the parent and child, or if a server caches
	the information for the other half of the delegation, then a server
	will have more types of data at a delegation point than a parent is
	supposed to hold.  (E.g., if a parent zone's name server caches the
	SOA for the child, the SOA is not in the parent zone, but is in the
	server's cache.)

	3.1 Child Is Secured Bit

	This section is written assuming the current definition of NXT holds. 
	There is some controversy surrounding the NXT record which may result
	in a complete replacement of it for proof of non-existence.  The
	current NXT definition provides an extension bit in the types present
	bit map, whose use is remains incompletely defined.  The following
	text largely ignores these uncertainties, and should be rewritten to
	accommodate these uncertainties in revisions.

Here is exaclty what RFC 2535 says about the first bit in the type
bit map in its RDATA:
*  "The first bit represents RR type zero (an illegal type which
*  can not be present) and so will be zero in this format.  This format
*  is not used if there exists an RR with a type number greater than
*  127.  If the zero bit of the type bit map is a one, it indicates that
*  a different format is being used which will always be the case if a
*  type number greater than 127 is present."
However, no other format has actually been specified.

	In the parent's half of the delegation point, there will be an NXT
	record.  According to the rules for a delegation point, only the NS,
	NXT, and SIG bits will be turned on in the types present field,
	assuming we drop the KEY set altogether.

	The KEY bit in the parent's NXT types present bit map is hereby
	redefined to have the following meaning.

	If the bit corresponding to the KEY RR set in a parent NXT is set, the
	parent has signed a KEY RR set for the child that includes a zone
	signing KEY RR (2.a).  Furthermore, the validity period on the SIG
	(KEY) RR covers the current time and the public component of the key
	used to generate the SIG (KEY) RR is validly available from the
	parent.

This is a very interesting idea.  Even though the only case where a
child zone KEY RR really needed to be in the parent was the insecure
AND cluelessly administered child case, using a bit in the parent NXT
makes things even more compact for the parent.  And I don't see
anything wrong with the part about the parent SIG public key being
available.

	E.g., Assume the zone "test." signs a key for "zone1.test.," with the
	signature valid from May 1st to June 1st and a public key from "test."
	available from April 1st until July 1st.  The NXT record for
	"zone1.test." will have the KEY RR bit set from May 1st to June 1st.
	This constraint may be enforced in the SIG (NXT) RR validity period,
	timely editing of the master file, or whatever other mechanism "test."
	chooses to implement.

	Conversely, if the bit is 0, then the child is not secured.  Note that
	for a fully secured zone (section 2.1), the bit is on (1).  For all
	unsecured zones (section 2.3) the bit is off (0).  For privately
	secured zones (section 2.2), the setting of the bit is determined by
	whether the parent signs the child's keys or not.  Hence, for
	privately secured zones, the parent may have no responsibility.  A
	child wishing to have the parent set the bit must contact the parent.

I suppose it doesn't really have much effect here but I think it is
important to retain the ability to set up local versions of root or
lower zones and the like.

	3.2 Rules Governing the Bit

	In this section, the words of the previous are turned into definitive
	MUST and SHOULDs.  Note that this section does not refer to the bit in
	the NXT.  This is in anticipation of a change in the way NXT indicates
	types present (e.g., if bit 0 of the field is defined) or a successor
	to the NXT is defined.

	3.2.a. At a delegation point, a parent zone MUST have a mechanism in
	place to indicate which RR sets are present.  The mechanism MUST
	indicate that the NS, SIG, and the type(s) corresponding to the
	mechanism itself are present (of course, with these types actually
	being present).  With the exception of the KEY RR type, all other
	types MUST be indicated as not present, and, in accordance with
	delegation rules, actually be absent from the zone.  If, in the
	future, other data is permitted to be present at a delegation point,
	this requirement MUST be amended.

"Actually absent form the zone" seems exessive. It shouldn't hurt if
miscellaneous other RR types happen to be at the server due to caching
or serving up the child so I don't see how having them in the zone
would cause any problem, at least with security.

	Assuming the NXT record, the above requirement reads as follows.  At a
	delegation point, a parent zone must have a secured NXT record.  This
	NXT record must indicate that the NS, SIG, and NXT types are present.
	With the exception of KEY, all other types must be indicated as not
	present.  The lower casing of the word "must" is intentional,
	conveying that this is an explanation of the rule above.

	3.2.b. The KEY set MUST be indicated as present during the time when
	the parent has issued a signature for the child's KEY set. Conversely,
	during periods of time in which the parent knows it has not generated
	a signature for the KEY RR set, the KEY set MUST be indicated to be
	absent.

	If the parent has issued signatures with discontinuous validity spans,
	then the presence of the KEY set will flip from present to not present
	and back as time progresses.

This seems like a pain but I can't think of any alternative right now.

	If the parent is aware that the child's keys are becoming valid or
	will be becoming invalid at a certain point in time, it is recommended
	that this be reflected in the NXT's signature validity period.

	3.2.c. When signing a child's KEY RR set, a parent SHOULD carefully
	consider the algorithm of the key used to generate the signature.  The
	parent SHOULD make clear to child zones what steps are to be taken to
	get the parent to indicate that the child is signed.  This document
	will go no further in specifying operational considerations.

	(Let's say the parent signs the child's key set with an algorithm the
	child can't process.  The child could elect not to advertise this
	signature as it cannot verify that the signature covers the real key
	set.  If this happens, is the parent justified in claiming that the
	child is secured?)

It's not worth worrying much about this.  In protocol terms, the
parent is in charge.  If the parent indicates a child is signed and
the signed zone KEY of the child is not available from the DNS, then
for secure resovlers descending through that parent, there is no
service for that child.  That is, they know its signed but they can
never get the public key to veryify any SIGs they might get form it.
So they know verified SIGs are required but, if they get SIGs, they
can never verify them, so they can not provide data in response to any
request that does not have Checking Disabled inicated.

If the parent thinks the child should be avertising some parent signed
child zone key, either because the child requested the parent to sign
it or the parent directed the child to do so, the parent should
indicate the child as secured.  There will be all sorts of
relationships between parent and child, from children being branches
of a parent company and subject to its orders to arms length
commercial relationships where the child has purchased DNS service
from the parent.

If the child is a branch of company X and the parent is the home
office, there is no need to mandate this behaviour.  If the parent has
real world authority over the child (like the child is a branch of a
company and the parent is the company headquarters), the parent may
not want to permit the child to become insecure.  Mandating the
CAPABILITY, however, is quite reasonable.  Should say something like
"The parent MUST have the capability of allowing the child....".

	3.2.e. The parent SHOULD NOT allow the child to request that the KEY
	set be indicated in the absence of a key signing request.

Reasonable.

	3.3 Operational Considerations

	Retrieving the NXT for a delegated name from the parent zone (the
	upper NXT) is not a trivial operation.  The complication arises due to
	having an NXT in the delegatee (the lower NXT) that matches the owner
	name of the upper NXT.  (The case in which both the parent and child
	zones are secured is the only case mentioned here.  If both are not
	secured, then there will be at most one NXT, which is easily
	retrieved.)

	There are two complications to describe.  One involves the multiple
	NXT sets matching the same owner.  The other is the pragmatic issue of
	knowing where to get the answer.

	With multiple NXT sets at the same owner, caches may become a problem.
	If a (for example) recursive server has cached the lower NXT, any
	query for the upper NXT may be confused for a lower NXT query.  This
	is akin to the issue of the ANY query, where a server with some cached
	data will answer with just that and not seek the rest of the data.

This topic has been brought up before.  I thought implementors had
indicated that it was "trivial" to tell the lower and upper NXTs
apart, based on either the type bit map, or on the relationship
between the owner name and the next name field.  The cleanest solution
to this would be to add a new RR type, perhaps called APEX, exactly
the same as NXT except for RR type number.  Then you use APEX at zone
apexes and NXT everywhere else and these difficulties are
substantially reduced.  But, of course, that is a change.  On the
other hand, if there were a consensus to change NXT for other reasons,
perhaps this could be rolled into that change.

	A resolver may know the child's server's addresses and the parent zone
	may not be sharing servers with the child.  In this case the resolver
	will need to be able to locate the parent zones (possibly having to go
	to the root servers and descend) in order to obtain the upper NXT
	record.

	A potential solution to this is to define an NXT meta-query which will
	force a recursive server to find all available NXT RR sets for a given
	name.  Details of this have not been examined.

	3.4 Interaction with Dynamic Update

	Dynamic update [RFC 2136, draft-ietf-dnsext-simple-secure-update-
	xy.txt] defines a means by which a zone can change without undergoing
	a full reload.  This combination of dynamic update and the proposed
	use of the NXT record to signify a child's status raises some
	concerns.

	First a few elements need to be labeled.  There is an off-line signer,
	which is the process that signs zone data files away from the name
	server.  There is an on-line signer, part of a name server, that the
	dynamic update mechanism uses to sign the updated data.  Finally,
	there is an on-line key validator, perhaps a misnomer, which accepts
	requests for parent signatures over each child zone's keys.

If you have on line signing capability, then doing the main zone
signing off line doesn't add much security and you could really do it
all on line.

	The proposal depicted in this draft relies upon the on-line key
	validator informing the on-line and off-line signers of the status of
	a child, recall that the status of a child has a temporal element. 
	E.g., a signature may be generated for just the month of July, so the
	child is secured for the month of July, but not August.

	The first issues pertain to the way in which a validation is encoded
	in an NXT record by the off-line signer.  There is a need for the
	status information to flow from the on-line validator to the off-line
	signer and then be used as input to the signing process.  The way that
	this information makes the transition is an issue.  The second issue
	is through what mechanism is this information ingested into the NXT
	generating process.  Recall that all other information can be derived
	by the zone data, the status of the child isn't stored anywhere else
	in the parent zone.

	The next issue is the means in which a validation action is reported
	to the active zone.  On the surface, dynamically updating the NXT
	would seem to make sense, but updating the NXT in this manner can lead
	to a race condition in the server, this is unstable.  The issue here
	is deriving a mechanism by which a name server knows to signify that
	the child status has changed.  Note that this applies to newly
	validated keys as well as the granting of a child's request to cancel
	a validation.

Given the loosly synchronized nature of DNS and such possibilities as
a multi-level zone splitting off children or a child and parent
combining, I feel virtually certain that there are plenty of race
conditions out there.  But how much of a problem are they in reality?
Could you say a bit more about the particular race condition you see?

	The final issue is the operation of the off-line signer.  When an NXT
	is being regenerated, the old NXT is needed to see what the previous
	setting of the child's status had been.  The old NXT signature is also
	needed to know that, had the child been known to be secured, for what
	interval was is it thought to be secured so that the new NXT signature
	is appropriately set.  Of course, if the reason for updating the NXT
	is a change as described in the previous paragraph, the old NXT is of
	lesser value.

Well, the information is needed, but that doesn't need to be back
derived from an actual NXT RR.  Seems to me that all this calls for an
auxiliary table.

	The issue raised in the last paragraph leads to a questioning of the
	sanity of using signature validity periods to signify the temporal
	status of data in a server.  What does a server return if the NXT
	needed is not currently covered by a valid signature?

Due to data caching, etc., seems like you have to encode the validity
interval in the RR data.  There are all kinds of ways that the data
could be screwed up.  The part of the server actually answering
queries should just do the best it can with the data available to it.
If NXTs or SIGs or whatever are missing from the on line zone, it is a
problem with the software that should be generating those RRs or
perhaps an operational problem...

	4 NULL keys

	Through the use of the types present to indicate the existence of a
	signature validating the KEY set of a child, the need for NULL keys
	effectively disappears.  NULL keys are left as a defined entity, but
	are rendered meaningless in DNSSEC.

	5 Experimental Status

	Without NULL keys, an experimentally secured zone cannot be defined as
	it is in RFC 2535.  The purpose of an experimentally secured zone was
	to facilitate the migration from an unsecured zone to a secured zone.

	The objective of facilitating the migration can be achieved without a
	special designation of an experimentally secure status. Experimentally
	secured is a special case of privately secured.  A zone administrator
	can achieve this by publishing a zone with signatures and configuring
	a set of test resolvers with the corresponding public keys.  Even if
	the public key is published in a KEY RR, as long as there is no parent
	signature, the resolvers will need some preconfiguration to know to
	process the signatures.  This allows a zone to be secured with in the
	sphere of the experiment, yet still be registered as unsecured in the
	general Internet.

Well, this doesn't quite do what "Experimental" does.  The current
Experimental is such that you can set up everything for a zone exactly
as if it were secure and then add a NULL KEY (per algorithm according
to RFC 2535 but per zone is better).  That means that you have to seek
SIGs and check them if you get them but if the server you are querying
is claiming there aren't any SIGs, that's OK.

	6 IANA/ICANN Considerations

	This document does not request any action from an assigned number
	authority nor recommends any actions.

	Without a means to enforce compliance with specified protocols or
	recommended actions, declaring a DNS zone to be "completely" secured
	is impossible.  Even if, assuming an omnipotent view of DNS, one can
	declare a zone to be properly configured for security, and all of the
	zones up to the root too, a misbehaving resolver could be duped into
	believing bad data.

	                     If a zone and resolver comply, a non-compliant or
	subverted parent could interrupt operations.  The best that can be
	hoped for is that all parties are prepared to be judged secure and
	that security incidents can be traced to the cause in short order.

	8 Acknowledgements

	The need to refine the definition of a secured zone has become
	apparent through the efforts of the participants at two DNSSEC
	workshops, sponsored by the NIC-SE (.se registrar) and CAIRN (a
	DARPA-funded research network).  Further discussions leading to the
	document include Olafur Gudmundsson, Russ Mundy, Robert Watson, and
	Brian Wellington.

	9 References

	...

	10 Author Information

	Edward Lewis NAI Labs 3060 Washington Road Glenwood, MD 21738 +1 443
	259 2352 <[email-masked]>

	11 Full Copyright Statement

	...

Hope these comments are helpful,
Donald

=====================================================================
 Donald E. Eastlake 3rd                      [email-masked]
 65 Shindegan Hill Road, RR#1                     +1 914-276-2668(h)
 Carmel, NY 10512 USA                             +1 508-261-5434(w)