Subject: Re: DNSSECbis Q-11: KEY RRs at delegation points

From: Edward Lewis <[email-masked]>
Date: Wed, 28 May 2003 15:04:41 -0400

At 14:25 -0400 5/28/03, Scott Rose wrote:
>However, there is no harm to the protocol by allowing it, is there?

The problem is that it is a return to the bad old days of data 
replication.   We survive the NS RR dilemma via the rules of 
credibility in RFC 2181 (which sorely needs to be promoted to PS 
soon) and the fact that this replication is so well ingrained in DNS 
that resolvers all know about it and deal with it.

There's no good that can come out of unsigned KEY RR's as any 
validator worth its salt will need the SIG RR's to make user of them. 
That means you might encourage QTYPE=SIG, which is a real bear, as 
you will get back all SIG's for the apex (SOA, KEY, NXT, NS, etc.) if 
you bother to ask.

I'd say that there are two harms - replicated data and larger 
responses - if you do this.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Digital cameras are to film cameras as Etch-A-Sketches are to canvases.

--
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: Derek Atkins <[email-masked]>
Date: 28 May 2003 17:12:23 -0400

Well, then, perhaps we should think of another way to doing it?

We're already proposing to change all the DNSSec RR Types.  Sam's
draft makes credible arguments why we need to make the change, create
a real "flag day" for DNSSec.  Accepting his proposal turns back the
clock, so to speak, on any existing deployment of DNSSec software, as
everything out there is going to be unaware of the new (revved) RR
Types.  So, if we're going to initiate a real flag day with new RR
Types for all of DNSSec, why not take it one step further and fix this
problem for good: introduce a SIG Bit?

For those who haven't heard of this proposal, in short you reserve one
bit in the RR Type to signify "this is a signature".  For example, the
RR Type for an A record (0x0001) would produce a SIG(A) by setting the
'sig' bit in the RR Type (e.g. 0x7001).  In other words, each existing
RR Type would imply an individual SIG RR Type for signatures over that
original data.

The benefits of the SIG Bit are obvious.  Using the Sig Bit you can
specifically query for the Signature of any individual RR Type.  E.g.,
you can specifically query for SIG(A) vs. SIG(KEY).  It also
alleviates the problem at the Apex, because you can individually query
for the signatures on any RRType you wish.  Moreover, this should
reduce the complexity of resolvers, caches, and authoritative servers,
and should also improve the chances of reasonable responses.  Even
better, the sig bit is less prone to errors in intermediaries and
would probably work through legacy, non-dnssec-aware devices (provided
they support "unknown rr types").

The drawback of the Sig Bit is that it reduces by half the available
RRs from 64k to 32k.  Considering the number of RRs in use and current
growth rate, I don't think we should be in any fear of running out
anytime this century.  IMHO, the benefits of reduced complexity,
reduced response size, and the ability to query for individual
signatures far outweigh the costs of deployment delay and rr-type
namespace reduction.

If we proceed with the sig bit proposal, this would be the time to do
it, coincident with the rr-type changes.  I would even volunteer to
author the draft if the working group considers it a worthwhile
proposal.

-derek

Edward Lewis <[email-masked]> writes:

> credibility in RFC 2181 (which sorely needs to be promoted to PS soon)
> and the fact that this replication is so well ingrained in DNS that
> resolvers all know about it and deal with it.
> 
> validator worth its salt will need the SIG RR's to make user of
> them. That means you might encourage QTYPE=SIG, which is a real bear,
> as you will get back all SIG's for the apex (SOA, KEY, NXT, NS, etc.)
> if you bother to ask.
> 

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Edward Lewis <[email-masked]>
Date: Wed, 28 May 2003 17:53:06 -0400

>bit in the RR Type to signify "this is a signature".  For example, the

Does anyone have a copy of Ohta's proposal, as referenced in a 
message on the dns-security mailing list on Wed, 14 Dec 1994 from Jim 
Galvin?  Rumor has it that Ohta proposed a similar idea, but I can't 
find any documentation of his proposal, only quotes like "The problem 
is that you, Jim, can't understand." (Citing a message sent on Wed, 
24 May 95 22:00:48 JST).

...Some things just don't change...

One reason the sig bit is a problem now is that it mucks up the NXT - 
requires an extended format to be used.

I can say that in theory a sig-bit approach has a certain appeal, it 
falls in line with my recent railing against option bits and for 
leaving "signalling" to be done in the Q-"trinity."  But on the other 
hand, the proposal is nearly a decade late now and I for one am 
tiring of the topic.   Others have even better, further-ranging, 
ideas based on a similar construct.  I don't want to steal the 
thunder of the folks who have thought up "slabs."  That has appeal 
too, but, we're a bit too far down the road to go back.

...Perhaps if in '94, more DNS folks had a say in what went on in 
DNSSEC and there was less concern about the underlying 
crypto...hindsight is hindsight.

PS - I encourage folks to peruse the old dns-security mailing list 
archive, if just for entertainment purposes.  It's somewhat 
interesting to look back with 5-9 years hindsight and see where and 
when we went wrong - and right.  But that's true in all endeavors, 
lest you be doomed to make the same mistake again.

---

From: Matt Larson <[email-masked]>
Date: Wed, 28 May 2003 18:17:39 -0400

On Wed, 28 May 2003, Derek Atkins wrote:
> So, if we're going to initiate a real flag day with new RR

No, stop, please stop.  We must resist the temptation to tinker with
anything but the type codes (and, I now reluctantly agree, the
mnemonics).  It's a slippery slope otherwise.

Matt

---

From: Sam Weiler <[email-masked]>
Date: Thu, 29 May 2003 02:41:45 -0400 (EDT)

On 28 May 2003, Derek Atkins wrote:

> ... why not take it one step further and fix this

See my 20 March message with subject "A Plea for Restraint".

As Ed points out, the implications of a(n) (RR)SIG bit are
non-trivial.  For more complications, note that RFC 2929 allocates
65280-65534 (0xFF00-0xFFFE) for private use.  It would be unseemly to
revoke that allocation, potentially breaking applications that (ever
how novel it may be) actually follow the spec's guidance re: what
numbers to use.

-- Sam

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 29 May 2003 17:22:21 +0200

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

> This was a sidebar topic in Q-8:  non-zone KEY RRs at the apex.
>
> Q:  Should KEY RRs (any) be allowed at delegation points?

Yes.

Otherwise, future DNS extensions are excluded from placing KEY RR's at
delegation points.  I.e., if DNSSECbis says KEY RRs MUST NOT be
present at delegation points, prudent resolvers will reject them (or
worse) if they are encountered, which could be harmful in the future.

However, it is fine to say explicitly that DNSSECbis does not attach
any semantics to KEY RRs at delegation points, and that the RFC 2535
usage for KEY RRs at delegation points is deprecated in favor of DS.

Paul Vixie <[email-masked]> writes:

> yes.  in addition to ed lewis's fine comments, the rule (made implicitly
> in 1034 and explicitly in 2181) is that everything at or below a
> delegation point is authoritative only in the child.  this means NS and
> A RRs held in a parent zone that are at (NS) or at or below (A) the
> delegation point, are just hints.  if the parent is queried for them,
> the result should be a delegation to the child.

Right.  1034 and 2181 also does not say that only NS and A RRs are
glue records.  It may be useful to make KEY RRs glue records in the
future, similar to how AAAA became useful as glue records.

   "Glue" above includes any record in a zone file that is not properly
   part of that zone, including nameserver records of delegated sub-
   zones (NS records), address records that accompany those NS records
   (A, AAAA, etc), and any other stray data that might appear.

> therefore anything present in the parent zone which is at or below a
> delegation point is only to be used for delegation responses.

Exactly.  It does not make sense for DNSSECbis to disallow KEY RRs at
delegation points, if someone wants to use them as glue.  DNSSECbis
should be silent on what constitutes glue records, just like 1034 and
2181 are.

> since a KEY RR is not used in delegation responses in a the DS world we
> are moving to, it should be an error to specify one at or below a 
> delegation point in a parent zone.

DNSSECbis allows the KEY RR to be used for (as of yet undefined) DNS
operations, some of those DNS operations may find it useful to use KEY
RRs as glue records.

I could not understand what harm allowing KEY RRs at delegation points
would have, although your answer was supposedly intended as backing
that point.  Would you mind explaining the exact harm?  E.g.,
complexity, efficiency, round-trips, or packet size.  I claim the harm
of disallowing them is that future (non-DNSSEC) DNS extensions are
excluded from using KEY RRs as glue records.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 29 May 2003 12:48:38 -0400

>future, similar to how AAAA became useful as glue records.

4.2.1 of RFC 1034:

#         To fix this problem, a zone contains "glue" RRs which are not
# part of the authoritative data, and are address RRs for the servers.
# These RRs are only necessary if the name server's name is "below" the
# cut, and are only used as part of a referral response.

Glue records are just the address records, not the NS RR's, 
(apparently) required to reach "down" below the zone cut.

>It does not make sense for DNSSECbis to disallow KEY RRs at

If you allow KEY RR's to appear at delegation points (that is, in the 
parent zone of the delegation), you are introducing a new case - 
non-address glue records.  This would include changes to AXFR.

>excluded from using KEY RRs as glue records.

The harm is that in allowing this to happen you are introducing 
something with is precedent setting.  When this is done, you will 
then have to go through and stamp out all the "corner cases" that pop 
up as a result.  This is an architectural danger - making a 
significant change like this.

The harm in the operational sense is that you are now accommodating 
replicated data - besides having to make sure the DS RR set is 
correct, you want to make sure the KEY RR set is in sync - just like 
you have to with address glue.

Another harm is that when the KEY records appear, the parent will 
feel obliged to return them, enlarging the response.  Is this a 
savings?  Well, no, because in a referral, the resolver will then be 
contacting the authoritative source anyway and will see the KEY RR 
set again because the authoritative source has no way of know whether 
or not the querier has the KEY RR set from the parent.

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 29 May 2003 10:59:20 -0700 (PDT)

Edward Lewis writes:
> non-address glue records.

Au contraire.  By explicitly disallowing KEY records, you are
introducing a new case, because no other record type is currently
explicitly disallowed at delegation points in parent zones.

Putting a KEY, LOC, RP, PTR, or any other random record type in the
parent zone at a delegation point is nonsensical, and the record will
effectively be ignored by the parent server when it formulates
responses to queries.  This does not mean creating such records should
be forbidden - forbidding them serves no purpose, and if you require
servers to enforce the prohibition on such records, it complicates the
server for no actual benefit.  It also makes it harder to create
future extensions, as Simon noted.

> This would include changes to AXFR.

The existing AXFR specification says absolutely nothing about the
treatment of KEY RRs at delegation points.  My interpretation is that
they are transfered just like any other record type at any other name
of the parent zone, though as I'm sure you know, my interpretation of
AXFR (embodied in draft-ietf-dnsext-axfr-clarify-05.txt) is subject to
debate.

Also note that RFC2136 section 7.18 already implies that zone
transfers can include arbitrary data at and below a delegation point:

   7.18. Previously existing names which are occluded by a new zone cut
   are still considered part of the parent zone, for the purposes of
   zone transfers, even though queries for such names will be referred
   to the new subzone's servers.  If a zone cut is removed, all parent
   zone names that were occluded by it will again become visible to
   queries.  (This is a clarification of [RFC1034].)

> significant change like this.

If there are such corner cases, they already exist as a result of
people being able to create e.g. LOC records at delegation points.

> you have to with address glue.

Perhaps if you actually create a KEY record in the parent it should be
kept in sync with the child.  Or perhaps not.  It doesn't really
matter, because no one is suggesting that KEY records should actually
be created - they serve no purpose in the DNSSEC protocol.  The
question is whether there is any point in *forbidding* them.  What
operational harm is being caused by the fact that someone can now put
a LOC record in the parent zone and perhaps fail to keep it in sync
with one in the child?  Absolutely none, because no one actually does
that, and even if they did, it would be effectively ignored.  There is
no need for KEY to be treated differently.

> feel obliged to return them, enlarging the response.

Why should it feel obligated to return them?  Servers don't return
any other records just because they happen to exist at the delegation
point, and I don't see any special provisions for KEYs in the drafts.

Perhaps it would be helpful to re-cast Q-11 in the form "Should KEY
records at delegation points in parent zones be treated any different
from other random (non-NS, non-DS) record types?", and settle the
general question of what to do with random stuff at delegation points
outside the context of DNSSEC.
-- 
Andreas Gustafsson, [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Thu, 29 May 2003 14:19:19 -0400

>outside the context of DNSSEC.

Yeah.

I was under the impression that one implementation, BIND, refused to 
load out of zone glue - hence I interpret more tightly the words in 
1034 - the ones I quoted - as saying only address glue is acceptable.