Off-tree validation

[Edward Lewis <lewis@tislabs.com>]

I have been updating my drafts, and have come across problems associated
with having one's zone key signed by someone other than the parent.  This
is something I've resorted to calling "off-tree validation."  On-tree
validation refers to having the parent of a zone sign the child's public
key set.

                      test
                      /  \
               mycompany certifier
                 /
              labs

Nominal, on-tree, validation would require that labs. mycompany.test.'s KEY
set be signed by mycompany.test.'s zone key, and that mycompany.test.'s KEY
set be signed by test.'s zone key.  For now, assume test is the root, so I
can now assume that test's KEY set is trusted via preconfigured keys in all
resolvers throughout the world.

The important consideration is how a resolver would work in this world.  If
a resolver only trusts on-tree validation of zone keys, then the only
question that would ever need be asked is either whether the child zone has
keys validated by the parent or whether the child is secured.  (The
difference between the two questions is subtle, exists, but is not worth
considering right now.)  If the question is binary, the answer could be
just one bit long, and is why a proposal (in DNSEXT) want to use a bit in
an NXT to accomplish this and remove NULL keys from usage.

But in writing this proposal and putting out feelers on the namedroppers
list (DNSEXT's list) a question arose about off-tree validation.  So, the
questions I put to the dnsop list are:

Do you think off-tree validation is important or needed?
If so, how would it work?

The reason I ask is that off-tree validation appears to be hard to secure.
Assuming a resolver will trust a chain of keys up to a trusted root,
imagine what would happen in the above example if certifier maliciously
copies the labs zone, replaces the true apex KEY set and signs the false
set itself.  The zone has been "zone jacked" and certifier can do with it
what it wants.

The way to prevent this zone jacking is to have a zone indicate which zones
(or entities) can provide validation of the KEY set.  This record can't be
signed in the zone itself, lest it be 'jacked too.  The parent of the zone
is the logical signer of this record, as it is by the mercy of the parent
that the child zone exists.  However, the dilemma here is, if the child
doesn't trust/want the parent to sign the KEY set, why would it want to
have the parent sign a record (set) stating who is authorized to sign the
KEY set?

Now, if off-tree validation is used, the question of whether or not the
child is secured is no longer a binary question.  The answer may be a
series of domain names that may provide a valid validation chain.  This
seems to call for a new record type, which is not what I want to introduce.

So, for now, I'll continue writing drafts that assume only on-tree
validation and hope to hear off-tree situations.  I also have some pending
research work into off-tree validation - so don't interpret this as
something I want to stop.  I just want it to work.

Comments?

P.S.  What would the policy of the resolver using off-tree validtion be?
Must the label count always be reduced along the chain?

Perhaps there should be a recognized gTLD called "validator." or
"certifier." or "certauth." that is a recognized alternative to the parent
for validation.  To become part of this gTLD, the entity doing the work
would have to meet an acceptable level of assurance that the power
would/could not be abused.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

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