Re: Keys at apex problem

[ted@tednet.nl (Ted Lindgreen)]

[Quoting Dan Massey, on Apr 18, 20:59, in "Re: Keys at apex pro ..."]

> On Wednesday, April 18, 2001 at 04:20PM, Ted Lindgreen wrote:
   <which KEY is used where>
...
> I've tried to walk through this from the resolvers point of view, 
> The only real result is that now I have a headache...
> 
> This sort of intersects with how a resolver works discussion and  I
> think the answer is different depending on whether the resolver
> uses trusted keys (option A) or TSIG (option B).

I don't think so, but a agree it is very confusing, because
the definitions are'nt clear.
Let's first make some definitions (not sure if these are
the correct ones, but please bear with me):

   stub-resolver  <------->  cachingforwarder  <------->  Internet-at-large
   |                                        |
   |________________________________________|
	           Resolver

Now, the TSIG issue and the various options, are about how the
stub-resolver and the cachingforwarder deal with each other.
There are various possibilities here, and further complication
is caused by the the cachingforwarder perhaps being authoritive
for something the stub-resolver wants. Hmmm, I understand your
headache...

What I tried to say earlier, was how I think the "Resolver" should
behave in case of multiple SIGs and KEYs. Let's redo it briefly:

 - someone wants the ssh-KEY of east.isi.edu.
 - the Resolver goes topdown (from its closest "secure entry point",
   let's say it is the root, but see also below), but of course
   using its cache as much as possible.
 - the Resolver knows root is secured, finds a delegation for .edu,
   finds and checks the .edu zoneKEY, sees this is a real KEY so
   .edu is secured. It then finds a delegation for isi.edu, same
   story. Then, it finds again a delegation for east.isi.edu,
   again same story.
 - At this point, the Resolver knows 3 things:
   1. the zone east.isi.edu is secured.
   2. the zoneKEY of east.isi.edu.
   3. there is no further delegation towards the requested RR.
 - So now, the Resolver gets the requested RR plus its SIG
   and checks it against the zoneKEY of the zone where the RR
   is found.

Remark about ""secure entry point": we know that neither root,
nor .edu is secured currently, but isi.edu is. That changes
the above a little bit:
 - the Resolver, which is secure aware and preconfigured with
   the KEY of isi.edu, starts checking SIGs from there instead
   of from the root.

Now between stub-resolver (your laptop) and IETF conference
cachingforwarder.

Option B assumes:
 1. you trust the IETF conference cachingforwarder.
 2. you can use TSIG to be sure you talk with this
    server, and not some faked one.
 In this case, your laptop (stub-resolver) is just asking
 for ssh-KEY of east.isi.edu with CD clear. The IETF
 conference cachingforwarder is doing all the work above
 and gives you back the requested RR with AD set.
 (ALternatively, you could also use your trusted cachingforwarder
 backhome using exactly the same protocol. Easier to setup, perhaps
 trustworthier, but cause a bit of extra traffic).

Option B assumes:
 1. you trust nobody.
 2. your laptop stub-resolver has a secure entrypoint
    preconfigured.
 In this case, your laptop stub-resolver must do the checking
 walkdown, but can be using the cached info from the IETF
 conference cachingforwarder. Because your laptop stub-resolver
 is checking itself it can set the CD and ignore the AD bit from
 the cachingforwarder.

>  .... Consider this 
> scenario:

I think with the above both scenarios can be filled in, as
long you keep the order in mind:
1. find out which zone is authoritive for the requested RR.
   (in practice: look for NS RRs)
2. find out whether this zone is secured
   (by getting and checking the zoneKEY).
3. then get RR and SIGs check the SIG from that zoneKEY (and
   ignore any other SIGs).

> In my opinion, 
> "KEYs other than zone KEYs MUST not be stored at apex of a zone"
> keeps looking better.  

I tend to agree more and more with this. But also the idea of using
KEY RR for zoneKEYs exclusively (and use an other RR type for
anything else) looks appealing.

Regards,
-- Ted.