Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)

From: Edward Lewis <[email-masked]>
Date: Wed, 28 Mar 2001 10:48:07 -0500

I was about send another message on this topic today even before I saw your
reply.

We (CAIRN) were discussing this proposal and had a few questions.

(Coincidently referencing this section:
At 9:17 AM -0500 3/28/01, Ted Lindgreen wrote:
>  Now having dealt with the parental SIG, how about the KEY?
>  In contrast to the SIG, I can think of philosofical arguments
>  to have either child or parent to be authoritive. However, the
>  technical arguments are straightforward to make the same zone
>  authoritive for this RR as its SIG.
)

Some folks have A records at the zone apex (cnn.com comes to mind), which
leads me to believe that in the future some folks may have non-zone keys at
the apex.  This implies that the parent will be signing a mix of zone and
non-zone keys for such a delegation.

The idea of having the parent (.com) being authoritative for cnn.com's
IPSEC key seems somewhat "hard to sell."  I see the point of having the SIG
be at .com, and therefore the KEYs be from .com, but when we look at the
non-zone keys, having the parent be authoritative is a hard sell.

'Course there is the debate of whether a A at the apex is tasteful, but
that's not our call (we're just engineers).

>  For DNS to work, there is no reason to include the zone-KEY in
>  the child-zone, when its already in the parent-zone, blessed
>  with a parental SIG. The only reason, we have proposed to
>  have it self-signed in the child-zone is to make a key-rollover
>  work securily without additional security methods. With this
>  RRset in two places, there will be instances where both RRsets
>  are different. In order to have the resolver pick the right
>  one in case of a conflict, we propose that the child does not
>  set the AA-flag on queries for its KEY-RRset, and the parent
>  does.

There is a few reasons to have the data in the parent.  Cement trucks,
backhoes, and (for those in certain areas) shotguns are reasons. (;))  We
just had a cable cut severing us from the Internet, so we couldn't get to
the parent zone.  The upshot of this is that I may want to have self-signed
keys configured locally to continue secure lookups.  ('Course, who am I
protecting myself against - if the Internet "is down.")

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: [email-masked] (Ted Lindgreen)
Date: Wed, 28 Mar 2001 16:17:27 +0200

[Quoting Edward Lewis, on Mar 22,  0:29, in "Signature at parent  ..."]
> I don't know what to think about this proposal.  It is counter to a lot of
> background of DNS (e.g., the child's apex data being more credible than
> that at the parent).  I see that this issue gives rise to a conflict of
> credible vs. valid.

Yes, we agree that this is an anomaly. However, having been thinking
about it for a long time, I think I can explain it.

  There are more anomalies at a delegation point. For instance,
  both parent and child have the child's NS records. And at some
  time we saw the statement: "the child is more authoritive" for
  these RRs, very confusing....
  I could explain this strangeness to students by comparing it
  with roadsigns:
   In the country (parent) there signs with a cityname giving
   directional information how to get there.  At the city (child)
   boundary, the city has placed similar signs, but now they are
   declaring "the city starts here".  The country-signs are
   informational, thus not authoritive, the city-signs are
   declarations, thus authoritive.  Once this is understood,
   explaining glue-records is even more simple.

  However, with the parental SIG over the child's KEY, I could not
  possibly get away with this line of explaining, as it is clear
  that the parent is declaring "I have delegated this zone to the
  holder of this KEY, and I am signing for it with this SIG".
  Clearly, philosofically speaking, the parent is authoritive, not
  the child.  From our testbed, we learned that also technically
  there are strong arguments to let the parent be authoritive for
  its own SIG, arguments are maintainability, responsibility, and
  scalability.  We know this conflicts with the background of DNS,
  but so be it.  Also, this anomaly is not new, it was introduced
  already with the parental NULL-KEY for clueless childs.

Now for the childs zone file.

  We found that there are strong technical arguments to NOT have
  the parental SIG in the childs zone, even when its just glue.
  The same arguments as mentioned above (maintainability,
  responsibility, and scalability) are valid here. I know we accept
  the same NS and (glue)-A RRset's at parent and child, but there
  is little harm done when these RRset are not completely identical:
  we have a lame or an unused server, ugly, but not desasterous.
  However, having an invalid SIG causes a subtree to drop of the
  Internet. So, a SIG must not be in two places, thus the child
  must not include the parental SIG in its zone file.

> There are a number of cases to consider but are uninteresting (like the
> parent and child having the same KEY RR set for the child).  The
> interesting cases are when there are different data and when there is the
> concern of liability.

Yes, liability is an important concern. We think that this is served
best with our proposal:
 when the signer has its own sigs under his own control there is
 less possibility to screw it up, but if screwed up it's clear
 who is to blame for it.

 With the original idea, where KEY and SIG records are sent out-of-band
 and having parent-SIGs in childs zonefiles, the chance of a screwup is
 much larger, and the various involved system administrators will
 certainly point to each other to blame.

> When there are different data (probably just a different SIG RR) between
> the child and the parent, it will probably be true that the  (parent) key
> validating the SIG RR at the child is not available from an authoritative
> source (just caches).  This means that unless there is a glitch, the
> child's more credible key set won't be validated by a third party.
> Question: is it acceptable to accept less credibile data if it validates
> over more credible but unvalid data?  (Seems so.)

I'm not sure I understand this. In our proposal, the parent's SIG
over the childs KEY-RRset is in the parents zone file, and only
there. So, there are no conflicting SIGs. With the parent being
also (more) authoritive over the childs KEY RRset I don't think
this scheme can happen.

> Note that there is that "glitch."  This is essentially the time that an
> undesired key remains alive in a cache - up to a TTL value.  I don't think
> there is a way around this, DNS is not real time and we don't have a way to
> publish revokation lists.  (And I don't think that we want to define this.)

True, we think the secure aware resolver must be aware of the
possibility of such glitches and that we must write up an
unambigious way to solve it while preventing loops.

> If someone has discovered the private key and this is the reason for the
> key change, the attacker can get away with misuse of the key for only as
> long as the discovered key is signed by its parent.  Again, for the same
> reason above, I don't think we have a way to stop this period of
> vulnerability.

Yes, very true. Even when the parent performs an emergency
key-rollover, there will be cached (but valid!) old info around
for some time.

For this reason, we think that parents SIGs over childs KEYs must
have a short lifetime. Making re-signing easy helps. In our testbed,
we re-sign daily, so this vulnerability lasts one day.

> Now, as far as liability - that the parent might present data that
> invalidates a child or allows for a child to continue to fall prey to an
> attack (because a key is not withdrawn), I don't think this is an area we
> can engineer around.  Same arguement about the non-real time-ness and no
> revokation list ability.

True. But if a parent, especially a TLD, screws up in such a way,
it is not doing what it is paid for and should be liable IMHO. It
can also happen nowadays already when a TLD puts in wrong NS or
glue records.

> Finally, there is something that I am concerned about.  When a child
> changes their key, the key is sent to the parent who then signs it.  If the
> parent then publishes the key, the child hasn't had a chance to make sure
> the key wasn't substituted on the way to the parent.

This is not how it is proposed in draft-ietf-dnsop-parent-sig-00.txt.
The child only notifies the parent (such notify can be spoofed, but
is this is harmless). After the notify, the parent collects the new
KEYset, and checks that it is signed with the old KEY that the parent
still has in its zonefile. Only when it validates, the parent will
update it. So, substituting with a false KEY won't work.

Thanks Ed for your questions,
regards,
-- Ted.

---

From: Brian Wellington <[email-masked]>
Date: Thu, 29 Mar 2001 15:06:39 -0800 (PST)

> protecting myself against - if the Internet "is down.")

With this logic, why not just store everything at the parent?  In DNS, key
records are really no different than any other records.  A child should
be authoritative for and hold its own key record, just like it holds
everything else.

The argument about about whether to store KEYs and SIG KEYs in the child
or the parent was pretty well hashed out 3 years ago or so.  There were
many reasons to go either way, but a decision was made, and there exists
at least one implementation.  Changing this now would be a bad idea.

Brian

---

From: Edward Lewis <[email-masked]>
Date: Fri, 30 Mar 2001 13:52:11 -0500

>be authoritative for and hold its own key record, just like it holds

I don't follow this answer.  I was trying to support holding data at the
child (because the parent may be unavailable), meaning the child would be
authoritative.  Why did you think this implies that everything should be
stored at the parent?

>at least one implementation.  Changing this now would be a bad idea.

This doesn't mean it can't be discussed again.  If the decision 3 years ago
was "arbitrary" - meaning it was close and we just chose and implemented
one - then it holds no more bearing than a decision made with more
operational and implementation experience.

I do recall the dicsussion that lead to the recommendation to leave keys
out of the parent.  But this was a discussion that did not include TLD
operators.  We were concerned more about the liability of the parent than
in the workload encured in managing delegations.

Dilbert is an optimist.

---

From: Brian Wellington <[email-masked]>
Date: Fri, 30 Mar 2001 12:28:16 -0800 (PST)

> authoritative.  Why did you think this implies that everything should be

Because that's what you said.  "There is [sic] a few reasons to have the
data in the parent.", followed by said reasons.

> operational and implementation experience.

True.  But I'm not convinced that operation experience has shown that the
decision was wrong.  The argument now is that it's somehow easier to store
keys in the parent.  This is not true.  In both cases, the key must be
sent from the child to the parent.  In both cases, something must be sent
from the parent back to the child, whether this something may either be a
signed keyset or a confirmation doesn't change the fact that it's still a
message.

> in the workload encured in managing delegations.

I believe we were also concerned about the size of the parent zone if it
stored the KEY sets and their SIGs for each child.

Brian