Subject: Summary: DNSSECbis Q-8: Non zone KEYs at the apex

From: "Scott Rose" <[email-masked]>
Date: Tue, 6 May 2003 08:46:37 -0400

The language in the protocol document will remain as is:  namely, non-zone
KEY RRs SHOULD NOT be placed in the zone apex, but are not expressly
forbidden.  There is no consensus to make this a more stringent restriction
("SHOULD NOT/MUST NOT").  The view seems to be that there is no harm in
having non-zone DNSSEC keys at the apex as part of the KEY RR set.

There may be some benefit to allowing them and no really reason to make the
language read "MUST NOT be placed 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: Simon Josefsson <[email-masked]>
Date: Tue, 06 May 2003 16:01:47 +0200

"Scott Rose" <[email-masked]> writes:

> The language in the protocol document will remain as is:

The document currently says:

"All KEY RRs at the zone apex MUST be zone keys."

and

"Non-zone key KEY RRs MUST NOT appear at delegation names."

(Btw, use "delegation point" instead of "delegation name".)

> namely, non-zone KEY RRs SHOULD NOT be placed in the zone apex, but
> are not expressly forbidden.  There is no consensus to make this a
> more stringent restriction ("SHOULD NOT/MUST NOT").  The view seems
> to be that there is no harm in having non-zone DNSSEC keys at the
> apex as part of the KEY RR set.
>

Introducing either "SHOULD NOT" or "MUST NOT" is a change from RFC
2535, which allowed non-zone keys at the apex.  I don't see consensus
for any of them, rather the contrary.

Consider a department, example.org, which runs DNS for people in the
department.  However, one machine is run by a person with DNS clue, so
they delegate host.example.org to his machine.  Now, this person may
want to publish a SIG(0) for his host, to enable zone transfers from
his machine, but the current document forbids this (MUST NOT) and your
suggestion (SHOULD NOT) suggests this is a bad idea.  Recall that 2119
defines SHOULD NOT == NOT RECOMMENDED.

If there really has to be a 2119 statement about this, use MAY, which
is consistent with RFC 2535.

---

From: "Scott Rose" <[email-masked]>
Date: Tue, 6 May 2003 10:37:12 -0400

----- Original Message -----
From: "Simon Josefsson" <[email-masked]>

> "All KEY RRs at the zone apex MUST be zone keys."

Changed to "All KEY RRs at the zone apex SHOULD be zone keys." to make the
section consistant.

> "Non-zone key KEY RRs MUST NOT appear at delegation names."
I think this wording may be murky.  I think this might be a left over from
2535/KEY@parent days, but not sure.  A KEY RR really should not be placed
with the glue records of a delegation, since we are using DS for zone keys,
and all other KEY RRs should be at the apex of the delegated zone.

Is this the trouble spot?

Scott

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 06 May 2003 19:24:02 +0200

> Changed to "All KEY RRs at the zone apex SHOULD be zone keys." to make the

I must be unclear, let me reiterate: I object to any restriction (in
the DNS protocol) of the kind of KEY RRs allowed at the zone apex.

As I understand RFC 2535, there is no restriction of the kind of KEY
RRs allowed at zone apex nor delegation points.

Thus, adding SHOULD/MUST requirements to the DNSSEC rewrite should
only be done after consensus, if I understand the process of the
rewrite correctly.

What I've been asking for is if there is consensus about this.  Edward
answered that question (thanks!) but pointed at this thread only, and
I don't see consensus about adding MUST/SHOULD here.

> and all other KEY RRs should be at the apex of the delegated zone.

_Why_ shouldn't they?

If you believe they shouldn't be permitted, I'd like to see the
explaination.  I'm looking for more than your yes/no opinion.

The current document says they add processing time, but this is false
(the wasteful IF statement must be present for security reasons).

I can only see operational considerations that may justify adding this
restriction, such as size/roundtrip/cachesize that Edward mentioned.
But that belong in an operational document, not in the protocol
definition.  The DNS protocol should be applicable to more than the
public Internet.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 6 May 2003 15:34:02 -0400

>>  and all other KEY RRs should be at the apex of the delegated zone.

The comment is that the wording is murky.  What is a "delegation name?"

If it is meant to be "a zone cut," well, there ought to be no keys 
period at the name - no data except for the DS RR and NXT RR is 
authoritative there, and the NS RR is just a hint.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Note to pilots: a three-point landing SHOULD NOT include a wing.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 6 May 2003 15:21:04 -0400

>defines SHOULD NOT == NOT RECOMMENDED.

I'd like to ask about whether SIG(0) can be used to support zone transfers.

I've tried to think of a way to get this to work but haven't been 
successful.  BIND doesn't have the ability to do it in any current 
incarnation.

Looking at TSIG zone transfers, the process requires the hard coding 
of the TSIG secret and name in the configuration file (in situ or via 
include), instructing the server to only allow transfers signed by 
the key (by name), and then instructing any transfer request to use 
the key (by name).

The step I want to highlight in the TSIG description is that the 
servers each must have the shared secret hard coded in their own 
configuration.

For SIG(0), there is a need to transfer the crucial data - the public 
key - via DNS lookups.  What happens if the server slaving the zone 
has a copy of the zone already and goes to pull the new one - which 
has unceremoniously rolled the SIG(0) public key?  We get stuck...

I don't see zone transfer protection via SIG(0) ever being 
deployable.  'Course I'm wrong a lot, but no one has gotten it to 
work.

Note that zone transfers are not the only use of SIG(0), but I'd like 
to put zone transfers with it to rest.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 7 May 2003 08:49:15 -0400

----- Original Message ----- 
From: "Edward Lewis" <[email-masked]>
To: "Simon Josefsson" <[email-masked]>
Cc: "Scott Rose" <[email-masked]>; <[email-masked]>
Sent: Tuesday, May 06, 2003 3:34 PM
Subject: Re: Summary: DNSSECbis Q-8: Non zone KEYs at the apex

> The comment is that the wording is murky.  What is a "delegation name?"

Poor wording choice at the time (but that is the text as it is written for
now).  I think it should be "delegation point" or "zone cut".  Allowing a
KEY RR there would get messy.