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

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 31 Mar 2003 11:19:54 +0200

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.

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. 

Is this a proper interpretation? If so I am afraid that there are other
interpretations possible. The issue of how to deal with preconfigured keys
is not spelled out, shouldn't it?

-- Olaf

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

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

> configured in the resolvers configuration and does not live in the

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!

---

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: Paul Vixie <[email-masked]>
Date: Mon, 31 Mar 2003 14:38:34 +0000

> sizes, for example.  Otherwise, it seems a bit self-defeating.

agreed.

> Is there a reason for stating that a zone MUST have its secure entry point

not in my view.  this appears to be an overspecification.

---

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