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

From: [email-masked] (Ted Lindgreen)
Date: Thu, 24 Apr 2003 11:03:46 +0200

[Quoting =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?=, on Apr 24,  4:20, in "Re: Q-03: inclusion  ..."]

> Listed below in order of frequency of inclusion of KEY RRset
> in additional section:
> 	1. Always include covering KEY
> 	2. Include covering KEY on referral only
> 	3. Never
> Please express preference on which rule to pick, and why.

It should be 3:
 IMHO, one needs the KEY before we get anything else
 from a child to determine the security status. Then we
 go ask for specific RRs, and we don't need the KEY in
 the additional section as we have it already.

 Said differently:
 -- suppose we want: A host.dom.top.
    suppose we have: KEY from root preconfigured
 -- we ask "A host.dom.top." at a rootserver
    we get NS-glue plus DS+SIG for top from rootserver
    we check DS+SIG with KEY from root
 -- we ask KEY RRset for top from top-server
    we check the KEY RRset with the DS
      now we know that top is secured, that the
      delegation is valid, and we have the KEY.
 -- we ask "A host.dom.top." at a top-server
    we get NS-glue plus DS+SIG for dom.top. from top-server
    we check DS+SIG with KEY from top.
 -- we ask KEY RRset for dom.top from dom.top server
    we check the KEY RRset with the DS 
       now we know that dom.top-server is secured, that
       the delegation is valid, and we have the KEY.
 -- we ask "A host.dom.top." at a dom.top server
    we get A host.dom.top + SIG
    we check the sig with the dom.top KEY
 Thus: the moment we need the KEY we must ask for it anyway, it
 is never useful as additional info with other queries as we
 should have the KEY (== the security status) already by then.

> If rule 1 or 2 is selected we need to set rules about inclusion order.

not applicable, as 3 was selected.

> Should inability to include one or both of the KEY RRsets cause the
> TC bit to be set ? (RFC2535 said no)

No.

-- 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: [email-masked] (Ted Lindgreen)
Date: Thu, 24 Apr 2003 11:46:21 +0200

[Quoting "Olaf M. Kolkman", on Apr 24, 11:09, in "Re: Q-03: inclusion  ..."]
> On Thu, 24 Apr 2003 10:31:21 +0200
> [email-masked] (Ted Lindgreen) wrote:
> 
> > [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.
> > 
> 
> 
> 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. 

OK, yes, I misinterpreted Pauls sentence, I'm sorry.

But for the end result it does not matter: Paul, you and me, we all
agree that the KEY should not be included in the additional section,
because the validator very likely already has it cached.

-- ted