Comments on draft-ietf-dnsext-zone-status-02

[[e-mail] (Ted Lindgreen)]

> DNSEXT WG                                               Edward Lewis
> INTERNET DRAFT                                          NAI Labs
> Category:I-D                                            July 12, 2000
> 
>          DNS Security Extension Clarification on Zone Status
>                 <draft-ietf-dnsext-zone-status-02.txt>
> 
....
> 1.1 When a Zone's Status is Important
.... 
> 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

No. Only when the child zone is clueless, the delegating zone needs
to indicate that the the child zone is unsecured. Otherwise, it is
up to the child zone zone to indicate whether it is secure or unsecure.

> 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?

As soon as the child has declared to its parent that it will be
carrying its own zone-KEY (or NULL-KEY), the parent removes the
NULL-KEY for this child from its zonefile. It's from now on up to
the child to conform.

> 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.

No. If the parent is secured and no parent-signed NULL-KEY is
encountered in the childs apex, the child must be secured
as well.

So, again, for a non-clueless child, it is the child, by having a
zone-KEY or NULL-KEY in its zonefile, that states it is secured or
unsecured. The parents zone is only consulted to verify the SIG
over childs KEY, not whether it is a real zone-KEY or a NULL-KEY.

> 1.2 Islands of Security
....
> The popular term for the secured zones at or below subarea1 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. ...

I think it is important to note, that the resolver of interest must
not only be pre-configured with zone keys, but also with the
entry-point of such an island, as it does not get this info from
the (unsecured) parent. Without this knowledge the island remains
vulnarable for zone-hijacking.

> pre-configured with the zone key(s) for subarea1.  All other resolvers
> will not recognize this island as secured.

Agreed.

> 1.3 Impact on RFC 2535

> 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).
> 
> The definition updates RFC 2535's definition of a zone key.  The
> requirement that the protocol field be either DNSSEC or ALL is a new
> requirement.

This update seems unnecessary, see comments from Eastlake, Arends,
and myself on previous drafts.

> 2.c Off-tree Validation - Any authorization model that permits domain
> names other than the parent's to provide a signature over a child's
> zone keys that will enable a resolver to trust the keys.

A remark could be added, that resolvers of interest must not only
be able to use the alternative authorization model to verify the
zone-KEY, but must also know exactly which zones to expect to be
secured this way.

> 2.1 Fully Secured

A remark: from this definition, I conclude that:
1. RSA-signed zones are not Fully Secured
2. As long as the root is Unsecured, there is no zone can ever
   be Fully Secured at all.
And therefore that we should aim for Private Security to start
with, and perhaps forget about Full Security at all?

> 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

Because this requirement is already in RFC 2535, this is not an update,
but a clarification.

> 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.)

Again, this requirement is already in RFC 2535, so this is not an
update, but a clarification.

> 2.2 Privately Secured

Perhaps a remark or statement could be made, that the resolvers of
interest must know exactly which zones to expect to be secured.
With a handful of well-published islands of security, in which the
verification chain internally follows the delegation tree, this
seems possible to implement.
But large numbers of random, off-tree signed zones seems rather
impractible.

> 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.

Again, this requirement is already in RFC 2535, so this is not an
update, but a clarification.

> 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.)

Again, this requirement is already in RFC 2535, so this is not an
update, but a clarification.

Regards,
-- Ted.



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