Subject: Off-tree validation

From: Edward Lewis <[email-masked]>
Date: Wed, 12 Apr 2000 13:13:05 -0400

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

---

From: Jerry Scharf <[email-masked]>
Date: Wed, 12 Apr 2000 10:39:26 -0700

First you have to ask how a resolver/recursive server somewhere in the world 
would find anything outside the chain to the root or local config for KEY 
validation. As you said, you can't have the zone in question do it, since that 
is easily subverted. That makes this really a DNSEXT question rather than a 
DNSOP one.

To find the certifier, it does have to be the parent that points there. The 
justification I could see for this would be certifier can do a better job of 
KEY management for the zone than the zone can, as believed by the zone. That 
seems too weak to justify the massive addition in complexity to all of DNSSEC. 
Does anyone have a better justification?

jerry

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 12 Apr 2000 23:06:17 +0200

>set itself.  The zone has been "zone jacked" and certifier can do with it

Apex replacement wouldn't work.

[boring lecture - anyone who has read Scneider can skip this]

In any signature-based system, there has to be a key that the verifier 
trusts unconditionally (in PGP it's the user's own key; in hierarchical 
DNSSEC and the late unlamented PEM it is a worldwide "root" key; in 
Internet Explorer, Microsoft has taken the trouble to trust about 107 
different keys on your behalf. Check Tools/Internet 
Options/Content/Certificates/Trusted Root Certification Authorities for the 
list if you don't believe me).

If you can compromise that key, or get the resolver to trust an 
untrustworthy key, you can get him to believe anything.

Off-tree validation is important because it allows a set of cooperating 
zones to be *more* secure (more expensive to attack) than their parent 
zones (or the root key). But it doesn't help anyone outside that set.

The difficulty with off-tree signing (or any nonhierarchical signing 
method) is that you replace a tree-shaped graph of signatures and keys with 
a general graph; finding a path from the record you want to check to a key 
you trust in a general graph the size of the DNS is not particularly quick.

[back to topic]

the attack that works against off-tree validation is this, I think:

          APEX
      /        \
   zoneA     zoneB
     |         |    \
     |         |     \
   zoneAA    zoneBB   zoneAA
    (real)    (real)   (fake)

where all the lines are "parent has signed child's key", but the names
don't have to match up.

The problem is that KEY records don't include enough policy info; a SIG
says "I think this is a valid key", not "I think this is a valid key for
signing zoneBB, but not for signing zoneAA".

So if you want secure off-tree validation, you'd better trust the first key,
or have information not available in the current DNS specs.

Sounds right?

                      Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Apr 0 0:53:12 JST

Edward;

> child is secured is no longer a binary question.

It is not binary, from the beginning.

The answer can be: secured, not secured or unknown (because of server
failure or DoS).

That is, as I pointed it out from the beginning, authentication that
a zone is insecure is useless.

							Masataka Ohta

---

From: Edward Lewis <[email-masked]>
Date: Thu, 13 Apr 2000 12:03:36 -0400

>The answer can be: secured, not secured or unknown (because of server

Depends on which side you are looking at the problem from.

>From the zone side there are two states: secured and unsecured.
>From the resolver side there are three states: secures, unsecured, and not
sure.

I have been writing from the zone point of view.

>a zone is insecure is useless.

I disagree.

If I get an answer from a zone that has no SIG record attached, should I
seek the SIG record?  If I can be reliably (securely) told that the zone
has not signatures, I will accept the answer as it is.  If I am securely
told otherwise, I will ask for a better answer and (perhaps) discard what I
have received.  If I am told nothing, I should be able to identify the
point at which the uncertainty starts, and if I am a problem solver, I know
where to begin.

It is useful to know when to give up hope. ;)

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Apr 0 1:20:37 JST

Edward;

> Depends on which side you are looking at the problem from.

You are not looking at the problem.

> has not signatures, I will accept the answer as it is.

If you need security, you can't accept the answer and the result
is no different from the case of:

	> If I am told nothing,

If you don't need security, you don't need security.

> If I am told nothing, I should be able to identify the

There is no problem to solve, here.

							Masataka Ohta

---

From: Edward Lewis <[email-masked]>
Date: Thu, 13 Apr 2000 12:35:56 -0400

>You are not looking at the problem.
...
>There is no problem to solve, here.

Huh?  (Perhaps this should have been my response to your prior message.)

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Apr 0 1:45:18 JST

Edward;

> Huh?  (Perhaps this should have been my response to your prior message.)

Look at a mirror and you can see the problem.

							Masataka Ohta