Subject: Re: Q-03: inclusion of KEY records in additional records section

From: [email-masked] (Ted Lindgreen)
Date: Thu, 24 Apr 2003 10:31:21 +0200

[Quoting Paul Vixie, on Apr 24,  7:53, in "Re: Q-03: inclusion  ..."]

> #3.  the time the KEY is needed is the first time a validator sees a SIG
> with that keyname.  there is no way for a server to know when that's 
> occuring. ..

I'm getting very confused now...

The whole point of authenticated denial of existance plus verifyable
unsecurity, and thus why we need NXTs (see Note-1)) was, IMHO,
exactly to make sure that the resolver (see Note-2) "knows" when a
SIG must be present.

Note-1: And why some want OptIn to get rid of those NXT's where
        possible again.

Note-2: I see that Paul writes "validator" and "server" above, I'm not
        sure which validator/server that is supposed to be, I guess a
	server acting as secure aware caching forwarder?

Background:

In designing the resolver software, we constantly run against
this problem. In short, we are still debating which way to go:

1. Should the resolver go down the tree, determining the security
   status, and validating the chain of trust on the way.
2. Should the (stub-)resolver go right for the answer at the
   nearest caching forwarder, then ask for a SIG and then chase
   the chain of trust up the tree for validation?
3. Should we forget dealing with validation in the stubresolver
   and trust secure aware caching forwarders?

Ad 1. This means "a full service resolver", capable of following
      delegations. This is a much more complicated beast than
      the current stubresolvers we all use. If we go this way,
      some implementations may choose to go right to the auth.
      servers instead of using a caching forwarder. And this,
      in turn, may present a high load on the DNS system.
      Advantage of this scheme is that we don't need secure
      aware caching forwarders.
Ad 2. Extending a stubresolver to do this is easy. However, it
      means that if no SIG is found, the resolver is in the dark
      whether the RR is verifyably unsecure or spoofed. Thus we
      need to go top-down after all to check for possible
      verifyable unsecurity?
Ad 3. For this we need first to trust the secure aware caching
      forwarder and second to have some secure communication
      with it. TSIG works, but will not scale, I have not
      seen other implementations yet.

We think 1. is the most feasible way, and that leads to the
wish to get KEYs in the additional section when going into
a delegation.

-- ted

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 24 Apr 2003 11:09:56 +0200

> exactly to make sure that the resolver (see Note-2) "knows" when a

The way I read this:

An security aware server will not know if a validator (a client that
verifies the DNS data) already has a KEY in its cache. Only if the
validators cache sees a SIG made with a given key for the _first_ time
it will need to go and fetch that key. 

In other words once you verified one piece of zone data you have
cached the key-set to verify all the other pieces of zone data.

The question if the client (the validator in this case) needs to
validate the SIG i.e. if the validator is looking at data that is in
secure or insecure namespace (from the validators perspective) is
irrelevant to the inclussion of the KEY in the additional section at
the server side. Based on it's idea about the security status of a
zone a validator will know that it will have to get the key and verify
the data.

>       aware caching forwarders.
(...)
> wish to get KEYs in the additional section when going into

This is also the method that Juergen Pfleger (our student intern who
looked at the algorithm for a secure caching resolver) followed, we
think that is the most feasible way to.

The crux is that you will get a delegation with a DS RR (or the NXT RR
proving the DS non-existence) that is signed with the zone-signin key
from the parent. At the first delegation from parent to child you have
to do an extra query but once you had one delegation from the parent
you will have a fair change that key still lives in your cache.

--Olaf

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi