Subject: Re: DNSSEC protocol doc question: pre-conf keys.

From: Miek Gieben <[email-masked]>
Date: Mon, 31 Mar 2003 12:05:46 +0200

[On 31 Mar, @11:19, Olaf wrote in "DNSSEC protocol doc question:  ..."]
> 
> 
> I am going through the DNSSEC protocol modifications document (version
> 01) to get an answer to the following question:
> 
> 
>   Is it legal to have a pre-configured key (trusted-key in bind) that
>   is not included in the apex KEY RR set but that is used to create a
>   signature over that KEY RR set? 
> 
> 
> I've carefully read section 2 and section 4 of the document. But may
> have been looking at the wrong place for the answer.

In section 5 it says:

   An initial KEY RR can be used to authenticate a zone's apex KEY
   RRset.  To authenticate an apex KEY RRset using an initial key, the
   resolver MUST:

   1.  Verify that the initial KEY RR appears in the apex KEY RRset, and
       verify that the KEY RR has the Zone Key Flag (KEY RDATA bit 7)
       set to one.

   2.  Verify that there is some SIG RR which covers the apex KEY RRset,
       and that the combination of the SIG RR and the initial KEY RR
       authenticates the KEY RRset.  The process for using a SIG RR to
       authenticate an RRset is described in Section 5.2.

> Anyhow, the situation seems to be allowed by the following sentence in
> section 2:
> 
>   "For each private key used to create SIG RRs, there SHOULD be a
>    corresponding KEY RR stored at the zone apex"
> 
> Given the SHOULD, a resolver should be able with the case of a
> KSK which signes ZSKs in the apex Key RR set and that is exclusively
> configured in the resolvers configuration and does not live in the
> apex Key RR set. 

in section 5 it is a MUST, so this seems a contradiction to me....

Besides this, I also think that step 1. for the resolver is not necessary.
If there is a sig that matches, shouldn't that be enough?

grtz Miek

--
:wq!

--
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: Mon, 31 Mar 2003 12:37:13 +0200

Thanks Miek,

> The issue of how to deal with preconfigured keys is not spelled out, 
> shouldn't it?

Sorry, that statement is not true... It is spelled out in section 5
(*blush*).

--Olaf

---

From: "Scott Rose" <[email-masked]>
Date: Mon, 31 Mar 2003 08:09:45 -0500

As for the contradiction in sections 2 and 5:

I would say it "SHOULD" since it won't really break DNS to not have the
"secure entry point" key (either a zone or key-signing key) offline.  It
would be impossible to verify unless the key was pre-configured, but unless
local policy is "only accept verified RR sets", things will still work, just
not verify.

I could see where a zone would want to have the secure entry point offline.
The root zone could publish the key somewhere else, to reduce response
sizes, for example.  Otherwise, it seems a bit self-defeating.

Is there a reason for stating that a zone MUST have its secure entry point
key in the served zone?

Scott

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 31 Mar 2003 17:38:58 +0200

> I could see where a zone would want to have the secure entry point
> offline. The root zone could publish the key somewhere else, to reduce
> response sizes, for example.

That is why I looked at this in the first place.

I have argued for the fact that verifiers 'MUST' fail if they fail to find
a self signature over the trusted key. The reason for this is to be able
to signal that 'somethings is wrong'. However, I start to believe that
from a crypto/security point of view that argument is nonsense.

I thus agree with having the 'MUST' removed.

--Olaf

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