Subject: Re: Zone secure bit

From: Roy Arends <[email-masked]>
Date: Tue, 11 Apr 2000 16:50:54 +0200 (CEST)

On Mon, 10 Apr 2000, Edward Lewis wrote:

> I am rewriting a draft on zone's security status and have a question for
> which I'd like some feedback.  Without going into gory details and special
> cases, which is preferred:
> 
> 1) A proposal to use the KEY RR bit in a delegation points upper NXT to
> signify a signed child zone key and to do away with the use NULL keys
> altogher.  E.g., if the child's zone key has been signed by the parent, the
> bit is on, the child's key is optionally held by the parent (recommendation
> is not to).  

Thusfar this is an improvement.

> If there is no signed zone key for the the child, the bit is
> zero, and neither the parent nor child holds a signed NULL key.  

Ofcourse, the child could also be "privatly secure", having a signed KEY
set, signed by some other party. Was your intention with the KEY RR bit to
indicate that the child has a signed key-set, or, that the child has a
key-set signed by this parent ?

> In this
> case, the KEY RR bit in the upper NXT signifies whether or not the zone is
> secured.

If the answer to the above question is that the KEY RR bit indicates that
a KEY set was signed by the parent, the statement would not be true for a
'privatly secured' child. Else this would lead to a new interaction
between the parent and the child which could be administarivly
undesirable.

> 2) The previous proposal plus the option that the parent may choose to hold
> and sign a NULL key for an unsigned child.  In this case, the KEY RR bit in
> the upper NXT signifies that "there is a key for the child somewhere."

IMHO there's no specific need to have backward compatibility. Secure zones
can be counted on one hand. And there is still no final implementation
that fully supports RFC2535. 

Regards,

Roy Arends

If there is no God, who pops up the next Kleenex?
                -- Art Hoppe
--
[email-masked]                NLnetLabs
tel +31208884551                Kruislaan 419
|\ ||   _  _|_  |   _ |_  _     1098 VA  Amsterdam
| \||__| )(-|_  |__(_||_)_)     The Netherlands

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: Tue, 11 Apr 2000 12:13:34 -0400

>key-set signed by this parent ?

Good question.  Initially I thought the signifying whether the parent has
validated the child's keys is what is needed, rather than if anyone has.

The reason is that the time in which this bit is most important is in the
case in which a resolver is following the DNS tree down from a secure root
to the zone in question.  As each zone is decended, a hint about the next
zone's security is needed.

If the validation goes off tree, then it is hard for the resolver to know
if the zone is validated.  So perhaps there is a desire to have the parent
signify the child being validated by someone else.

But consider this example (which isn't directly related to the bit setting,
but is related to off-tree validation):

                      test
                     /     \
               mycom        certifier

Assume mycom and certifier are both properly validated by test.

If off-tree validation happens, "certifier.test." could hijack
"mycom.test." by creating a second keyset for mycom and signing it itself.
certifier could then claim that mycom is validated by certifier, which is
validated by test.  Any resolver configuring the test key would trust the
hijacked chain.

(As far as label count, sub.mycom.test. could be hijacked by
certifier.test., so that's no help.)

IMHO, if an off-tree signer is used, then this needs to be signified via a
record that is validated on-tree.

So, good question...

>between the parent and the child which could be administarivly

I don't want to create more interactions across delegations.

>that fully supports RFC2535.

Beside backward compat, after doing a rewrite based on Brian's comments,
the second choice is a bit cleaner.  However, given the off-tree validation
problem above, this may be muddled too.

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