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

From: [email-masked] (Ted Lindgreen)
Date: Thu, 20 Jul 2000 14:44:28 +0200

> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 21 Jul 2000 07:30:20 -0400

At 8:44 AM -0400 7/20/00, Ted Lindgreen wrote:
>> My Draft is double >'d
...
>up to the child zone zone to indicate whether it is secure or unsecure.

I answered this in a message to Roy.  "Stating" by being silent is still
stating.  It's like an appellate court refusing to hear an appeal of a
lower court case - the appellate court is "saying" that the lower court
verdict stands.

...
>encountered in the childs apex, the child must be secured

Perhaps I should point out that in section 1 I am describing the functional
requirements regarding the times at which I need to know the status of a
zone, in particular during verification of a name resolution. What we are
arguing is a requirement (stating the status) versus an implementaion (by
not saying anything if secure).

I believe you are looking at this from the perspective of the server.  A
few years back I wrote a resolver - which gives quite a different viewpoint
of the DNSSEC process.  If you had to slog through the resolver process you
might see what I am describing.

>and myself on previous drafts.

This update was offerred following consultation with implementers (i.e.,
folks other than myself).  We (including myself) that it was just good
programming practice to check the field.  All known signers to date do
this, so I thought it should be documented - lest some one want to reassign
the field's meaning later only to find that antiquated signers would have a
problem.

>> 2.c Off-tree Validation - Any authorization model that permits domain
...
>zone-KEY, but must also know exactly which zones to expect to be

This issue is a subject of a smoldering idea of mine.  I've floated a few
proposals over the years to address this - but the time for the proposal
hasn't arisen.  So I left that comment out.

What is important is that RFC 2535 is all about resolver security.  DNSSEC
is entirely targeted at making the world safe for the resolver.  Server's
are at the mercy of what the resolver thinks.  This observation is the
motivation behind this draft - even if the server admin does everything to
secure the zone the best that can be done, a resolver still might not see
the zone as secure.

>with, and perhaps forget about Full Security at all?

Your observations are correct.  I wouldn't "forget" about Full Security,
but just that we should know that until the root is fully secured and until
RSA is declared a mandatory to implement algorithm, an RSA signed zone may
not be judged to be secured by a minimally conforming resolver (i.e., one
that only allows a root key configured and knows only the mandatory to
implement algorithms).

Recall that the difference between being "Fully" and "Privately" secured is
just in name - a zone can switch from one to the other without moving a
finger.  E.g., you are set up and your parent (someone you don't control)
changes from Privately to Fully - and therefore so do you.  (Caveats
abound.)

>update, but a clarification.

Roy mentioned this...

>interest must know exactly which zones to expect to be secured.

I'll address this part of your comment only - I've tried to float an idea
here and it was mercilessly trashed.  Although I believe the zone should be
able to reveal to a resolver what the security parameters are ("I use NXT"
vs. "I don't use NXT"), we don't have enough experience to develop a
workable implementation of this.

...

>update, but a clarification.

Hmmm - since this is so obviously an accurate statement, either I was brain
fogged when I wrote this or there was some other intent when I wrote the
text about which you comment.  Either way, I'll need to address it.

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

"It takes years of training to know when to do nothing" - Dogbert

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