Subject: Wrapup: DNSSECbis Q-8: Non-zone KEY RR at the apex.

From: "Scott Rose" <[email-masked]>
Date: Fri, 2 May 2003 10:40:01 -0400

Considering I have not heard any negative replies to this message, I assume
there is consensus to change the wording to disallow non-zone KEY RRs at the
apex.

Unless some late comments come in.
Scott

> Q:  Should a secure (signed) zone be allowed to have non-zone KEY RRs in
the
> apex?
>
> Discussion:
>
> "Section 2.1 of draft-ietf-dnsext-dnssec-protocol-01
>
> To sign a zone, the zone's administrator generates one or more
> public/private key pairs and uses the private key(s) to sign authoritative
> RRsets in the zone. For each private key used to create SIG RRs, there
> SHOULD be a corresponding KEY RR stored at the zone apex. All KEY RRs at
the
> zone apex MUST be zone keys. (A zone key KEY RR has the Zone Key bit of
the
> Flags RDATA field set to one. See Section 2.1.1 of [10].) Zone key KEY RRs
> MUST appear only at the
> zone apex."
>
> <snip>
>
> "Other public keys associated with other DNS operations can be stored in
KEY
> RRs that are not marked as zone keys. Non-zone key KEY RRs MUST NOT appear
> at delegation names. Non-zone key KEY RRs also SHOULD NOT appear at the
zone
> apex, because large KEY RRsets add processing time at resolvers. Non-zone
> key KEY RRs MAY appear at any other name in the zone."
>
> /end
>
> The first paragraph quoted above states that only DNSSEC zone KEY RRs can
> appear at the
> zone apex.  The second quoted paragraph, states that non-zone KEYs SHOULD
> NOT appear.
>
> It is possible that an admin may wish to put a non-zone key (e.g. SIG(0)
> KEY) at the apex, which would be unwise, and result in a larger apex KEY
> RRset.  However, there are better ways to store such KEY RRs.
>
> Should the SHOULD NOT in the above (third) paragraph be changed to
"Non-zone
> key KEY RRs also MUST NOT appear at the zone apex, ..." ?
>
> Scott
>
>

--
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: Edward Lewis <[email-masked]>
Date: Fri, 2 May 2003 12:53:09 -0400

Well, since you are prodding for comments...

First question, what non-zone keys can sit at the apex?

Answer: SIG(0) keys, well, that's all I can think of.  If I'm missing 
something, then I'm missing something.

Second question, is there a reason to have a SIG(0) at the apex?

Answer: Perhaps...

...for zone transfer.  However, for zone transfers, SIG(0) 
authentication has not been implemented and looks like it maybe next 
to impossible.  (TSIG is configured into the server, so the secret is 
there, the SIG(0) public key might be in the zone being transferred, 
a catch-22.)

...if there is a host who's name is the same as the apex.  This could 
happen, a lot of web sites wanted to drop "www." from the "usual" 
domain name convention.  I'm not sure how useful SIG(0) would be 
here, I don't have the right experience.

...if you want to dynamically update the apex with a policy requiring 
that the name to be updated can only be changed with a same-named 
key.  I'd rather use an administrative key for the entire zone and 
not have anything special at the apex - but that's a personal 
preference, not a reason to legislate away the possibility.

So, when it comes to writing the spec, I might lean to the less 
restrictive "SHOULD NOT" than a "MUST NOT".  It seems to me that 
maybe there is a clear rationale for allowing SIG(0) at the apex, but 
no real need to exclude or include it.

Third question, did I miss something, is there a reason to bar SIG(0) 
use at the apex I haven't seen?

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

It's true, my last college class really was "Introduction to Ada."

---

From: Michael StJohns <[email-masked]>
Date: Sat, 03 May 2003 00:54:38 -0400

I've read Ed et als comments on this so am up to date:

Without making any comment on whether or not non-zone KEY RRs are 
useful/bad, if the restriction is adopted, it should probably be stated as 
a protocol restriction rather than a data content restriction.

E.g.  "A DNS server compliant with this specification MUST NOT serve a KEY 
RR which has the Zone Key bit set unless that KEY RR is at the zone 
apex.  A DNS server MUST set the Zone Key bit for all KEY RRs which are at 
the zone apex."

The proposed language depends on the operator doing the right thing, the 
above requires the server or protocol engine to do the right thing.

Possibly the right thing to do is take the proposed language and put it 
into a document which describes a BCP for operating a secure DNS server 
rather than placing it in the protocol document.

Mike

---

From: Edward Lewis <[email-masked]>
Date: Sat, 3 May 2003 11:30:55 -0400

At 0:54 -0400 5/3/03, Michael StJohns wrote:
>Without making any comment on whether or not non-zone KEY RRs are useful/bad,
>if the restriction is adopted, it should probably be stated as a protocol
>  restriction rather than a data content restriction.

That's certainly true, we have to discipline ourselves into thinking 
in terms of the protocol, not what is held.

>E.g.  "A DNS server compliant with this specification MUST NOT serve a KEY RR
>which has the Zone Key bit set unless that KEY RR is at the zone apex.  A DNS
>server MUST set the Zone Key bit for all KEY RRs which are at the zone apex."

The first MUST (NOT) - I suppose that is true, but isn't related to 
the original question.  I guess that there's no place for a zone key 
anywhere other than in the root.  I.e., a validator must not make use 
of a zone key that is not owned by the apex of a zone.

The second MUST - one important factor is that no DNS server is ever 
allowed to change any part of a zone, not even set a bit in the 
matter described.  The place where the bits are set are in the key 
generator or what ever prepares the zone data for signing.  (Once 
signed, changing a bit in the key flags would invalidate the 
signature on the key and would also change the footprint/keytag of 
the key.)

But I also don't see any discussion that proves that "only zone keys 
at the apex" is a defendable restriction.

>The proposed language depends on the operator doing the right thing, the above
>requires the server or protocol engine to do the right thing.
>
>Possibly the right thing to do is take the proposed language and put it into a
>document which describes a BCP for operating a secure DNS server 
>rather than >placing it in the protocol document.

Such a BCP has been boiling for about 5 years.  I feel that it won't 
happen until we have good protocol specs written first.  The reason 
is that each time the BCP was written, a protocol flaw was found, 
upending all the work in the BCP.  The challenge is to write the 
protocol specification without folding in the BCP material.  I'm not 
saying that that it is easy to do.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Rob Austein <[email-masked]>
Date: Sat, 03 May 2003 15:49:17 -0400

> apex.  A DNS server MUST set the Zone Key bit for all KEY RRs which are at 

Er, no.  The zone content is the zone content, and the name server
doesn't get to modify it on the fly (among other reasons, because
doing so would invalidate the signatures).

---

From: Paul Vixie <[email-masked]>
Date: Sat, 03 May 2003 20:11:12 +0000

> doing so would invalidate the signatures).

i took this to mean "shall refuse to serve a zone without this property,
for example issuing an error and refusing to load or reload a zone if this
condition is not satisfied."

---

From: Rob Austein <[email-masked]>
Date: Sat, 03 May 2003 16:28:24 -0400

> condition is not satisfied."

Right, I don't have a problem with that interpretation, but if that's
what we mean, it's probably what we should say :).

---

From: Michael StJohns <[email-masked]>
Date: Sun, 04 May 2003 14:31:33 -0400

>what we mean, it's probably what we should say :).

Hey, give me a break - I spent all of 5 minutes word smithing this stuff....:-)