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

From: Simon Josefsson <[email-masked]>
Date: Fri, 02 May 2003 17:46:48 +0200

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

> Q:  Should a secure (signed) zone be allowed to have non-zone KEY RRs in the
> apex?

Yes.

The only disadvantage presented as a consequence of putting non-zone
KEY RRs at the apex is that such usage may add processing time to
resolvers.

First, I question the amount of processing time wasted.  We are
talking about one IF statement, that checks if the Zone Key Flag is
set, for each KEY RR.

Secondly, if a zone administrator see a benefit of putting a non-zone
KEY RR at the apex, after having considered that it make resolvers
slower, she should be allowed to do so.

RFC 2535 do not include the SHOULD NOT you are referring to, as far as
I can tell.  When was it discussed on this list to introduce it?

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

Such as?

--
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: "Scott Rose" <[email-masked]>
Date: Fri, 2 May 2003 13:50:19 -0400

The restriction would primarily be to reduce the KEY RRset size.  Since
SIG(0) KEYs are usually for a host/entity it would seem that having an
update/zone transfer key with the same name as the zone might not be a good
idea.  Having another name "primary.zone" or "updatekey.zone" seems more
logical.  While most implementations would see the flags, a human admin may
make mistakes if they manually edit a zone file.

RFC2535 does not place any restrictions on KEY RRs at all.  Updating RFCs
(restrict KEY, etc.) have.  So it was brought up in the DNSSECbis writing
that some distinction should be made one way or the other.  Either disallow
non-zone KEY RRs or allow them.

Scott

---

From: Edward Lewis <[email-masked]>
Date: Fri, 2 May 2003 14:40:13 -0400

At 13:50 -0400 5/2/03, Scott Rose wrote:
>The restriction would primarily be to reduce the KEY RRset size.

I can understand that desire, but can the problem of KEY RRset size 
be quantified?  I want to be able to compare the cost of the extra 
size versus the cost of the lost flexibility.  Not that all lost 
functionality is bad, but it's bad if it is lost for little or no 
gain.

If we are going to specify away some otherwise legal configurations, 
there should be a rock-solid rationale in the accompanying text.

...Of course, I'm picking on perhaps just one aspect of the question 
here - whether or not SIG(0) KEY RR's are allowed at the apex.  There 
may be others I don't see.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

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

---

From: "Scott Rose" <[email-masked]>
Date: Fri, 2 May 2003 14:55:13 -0400

That's pretty much it.  No one has quantified it fully.  Large KEY RR set
sizes is mostly FUD unless you're talking VERY large keys.  Even then, the
problem was with DSA more than RSA.

Transaction authentication keys would be the only class of keys restricted
by it.  Unless some new use of the KEY RR for DNSSEC is adopted.  Zone and
KEY signing keys are still allowed.

Scott

---

From: Edward Lewis <[email-masked]>
Date: Fri, 2 May 2003 15:15:52 -0400

I'm against placing any restrictions or rules to counter FUD.  I'd 
rather let the suspected "badness" happen and then assess whether it 
needs to be corrected.

I'm not saying that there should be no restrictions - just no 
restrictions to counter FUD.

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 03 May 2003 00:54:24 +0200

> The restriction would primarily be to reduce the KEY RRset size.

The document says "add processing time at resolvers".  Is the document
incorrect?  Is the reason the KEY RRset size now?

If so, why forbid this scenario for an administrator that has
considered the consequences?

It is not like it destroys interoperability, or add any negative
consequences for anyone.  Resolvers doesn't have to implement anything
extra to support it.  It just works, but wastes a few bytes of
bandwidth.  Only the administrators using it will suffer.  Those
administrator can chose to not use it if they suffer too much.

> Since SIG(0) KEYs are usually for a host/entity it would seem that
> having an update/zone transfer key with the same name as the zone
> might not be a good idea.  Having another name "primary.zone" or
> "updatekey.zone" seems more logical.

Is there consensus about this?

If so, explain the solution in the document, so people that were using
valid RFC 2535 constructions can migrate to the new solution.  Don't
forget to discuss the migration issues.

> While most implementations would see the flags,

Any implementation that didn't would be insecure.

> a human admin may make mistakes if they manually edit a zone file.

Humans should use tools if they don't know what they are doing.

A human admin may make mistake today, mistakes that have more severe
consequences than forcing resolvers to execute an IF statement, that
must be executed anyway for security reasons.

> non-zone KEY RRs or allow them.

I think they should be allowed.

Non-zone KEY RR's should be allowed at delegation points too, which
the current update says MUST NOT about, whereas RFC 2535 didn't, as
far as I can tell.  This also wasn't discussed on the list, also as
far as I can tell.  Please raise this an issue to the list or revert
the modification, or point me to where this has also been discussed.

Thanks.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 2 May 2003 22:53:56 -0400

>considered the consequences?

Before we get caught in another contentiously toned thread, let's all 
just have a little understanding about the different perspectives 
that we have here.

First, it is important to get any rationale for any restriction 
clearly documented, or we will wind up with perfectly understandable 
questions such as Simon's.  It's not that I want to squelch Simon, 
but we should make as much as possible crystal clear.

Second, the reason to forbid a "scenario for an administrator who has 
considered the consequences" is that at times, what is good locally 
is bad globally.  E.g., allowing all users on the Internet to have 
portable addresses is good for them, but bad for the routing tables. 
Doing the reverse - relying solely on provider based addressing can 
optimize routing but has nasty consequences when a provider goes out 
of business.

It's a valid question to ask - do SIG(0) KEYs have a negative impact? 
The cost of carrying them is not borne (just) by the administrator 
that adds them, if is borne by the intermediate caches, the router 
buffers, and the end resolvers that have to deal with them.

I'm not saying that I'm for the restriction, but is perfectly 
acceptable to ask about it.

>administrator can chose to not use it if they suffer too much.

As I said before, I think that's untrue - the administrator is the 
one who suffers the least - if suffering means expending CPU cycles.

>Is there consensus about this?

No, but not every thing Scott says is intended as a consensus 
statement.  We are all entitled to make statements - even statements 
of conjecture.  As far as SIG(0) for zone transfers - I think that it 
is not promising at all - no matter what the key is called.  I've 
thought about it, tried a few things, but never documented my failed 
attempts.  With Scott's words, at least he out did me - getting it 
mentioned in the archives.

>forget to discuss the migration issues.

When folks can volunteer, this is done.  Remember that all input is 
volunteered here.  If you want more things to be said, make it known 
and better yet, help by contributing text.

Believe me, as one who is dragging his sorry carcass around the globe 
attending workshops and trying to document as much as is possible, 
folks are trying to do just that.  It's a lot of work.  If only I 
could write more...I would.

>Humans should use tools if they don't know what they are doing.

This is always true.  More tools are always helpful.

>the modification, or point me to where this has also been discussed.

I'm inclined to agree with Simon, given the limited knowledge I have. 
(I.e., I haven't spent time studying the problem beyond the thread 
here.)

"Point me to where" - I'd just send a link to your own message.  The 
documents are available for comments, read them, comment.  The 
editors have been begging for comments.

Think of the situation the editors are in.  They are trying to 
clarify a bunch of documents, starting with an original that was 
lacking in many areas.  Since the original a lot of patchwork was 
done.  In applying the patches, they've discovered holes and overlaps 
- should they just cut and paste or try to stitch them together?

Assuming the latter, you're going to get things that slip in without 
an explicit adoption by the WG.  Your chance to stop this is to make 
comments, as you have here, and call attention to issues.

But keep in mind that this is all done by volunteers...

---

From: "Scott Rose" <[email-masked]>
Date: Sun, 4 May 2003 14:58:55 -0400

----- Original Message -----
> Humans should use tools if they don't know what they are doing.

There is no consensus about naming keys for non-zone signing purpose.  There
was a question in the protocol draft about this.  I do think it is not as
severe as problem to warrent a special rule (i.e. saying "MUST NOT include a
non-zone KEY RR at the apex"), but since it was a big enough issue to
warrent a seperate note in the draft, I felt it should go through
namedroppers.

It seems so far in the discussion that most seem to think it does no harm to
the protocol in allow non-zone KEYs to have the same name as the apex.

Scott