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

---

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

---

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

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Thu, 24 Apr 2003 09:51:40 -0400

At 03:50 2003-04-24, Ted Lindgreen wrote:
> >       Additional section: glue addresses signed by gtld-servers.net.
>
>Glue was never to be signed, or has this been changed recently?
>
>-- ted

In this case the server is authoritative for .com and gtld-servers.net.,
so in this case the use of the word "glue" is wrong, but I'm not sure
what the right term is ?

         Olafur

---

From: [email-masked] (Ted Lindgreen)
Date: Thu, 24 Apr 2003 09:50:14 +0200

-- ted

---

From: Peter Koch <[email-masked]>
Date: Thu, 24 Apr 2003 21:41:52 +0200

Paul Vixie <[email-masked]> wrote:

> it's still glue.  the protocol doesn't permit a client to impute authority

it's not. "glue" is a term for data origin, i.e. there's a difference
between additional data and "glue". The client can't tell that difference.

> of additional data based on name-similarity to data in other sections which
> is claimed as authoritative.

Well, the client may not, but why shouldn't the server feed the additional
section with authoritative data - if it's signed?

-Peter

---

From: Paul Vixie <[email-masked]>
Date: Thu, 24 Apr 2003 20:27:28 +0000

> > > In this case the server is authoritative for .com and
> > > gtld-servers.net., so in this case the use of the word "glue" is
> > > wrong, but I'm not sure what the right term is ?
> > 
> > it's still glue.  the protocol doesn't permit a client to impute
> > authority ...
> 

correct, it may or may not be glue, depending on how deep the owner
names are.  and because the client can't tell the difference, it has to
be presumed "glue" or at least NOT presumed to be "authoritative".

> > ... of additional data based on name-similarity to data in other
> > sections which is claimed as authoritative.
> 
> Well, the client may not, but why shouldn't the server feed the
> additional section with authoritative data - if it's signed?

i don't know what the dnssec docset currently says about that, but
it sounds like a good idea (or a good interpretation if the docset
is ambiguous on the issue.)

this gets back to the TC question, though.  if the sig/key for
"authoritative additional data" is available and it will fit then
i see no problem in adding it.  if it's available but it won't
fit, though, then it ought not be added, and TC ought not be set.
so, it's additional-additional-data, or meta-additional-data.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 28 Apr 2003 16:22:13 -0400

At 16:10 -0400 4/25/03, Michael Richardson wrote:
>   I couldn't understand the origin of this whole conversation, except that
>Ed wanted #1 for a period so that we could understand the impact.

Naw, I was fer #3, DavidB was for #1.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

A compiler-directive person living in an HTML-tagged world.