Subject: DNSSEC and Parent SIG in Child zone

From: [email-masked] (Ted Lindgreen)
Date: Fri, 13 Oct 2000 15:49:40 +0200

Hi,

First some background:

Since the beginning of this year NLnet Labs is working in a CENTRE
working group to install of DNSSEC in the ccTLD zones of .se, .de,
and .nl. We encountered a number of technical problems, but these
proved to be solvable. Now we are focussing on the organisational
aspects.

We have run into an organisational problem for which we have not
found an acceptabel solution. The problem lies in the SIG record
over the zone KEY.

The problem:

In the implementation of both Bind-8.2.2p5 and Bind-9 this SIG
record, which is generated by the parent, must be put into the
child zone (and may also be put into the parent zone).

Despite numerous attempts, we have sofar not found a solution to
synchronize a KEY update in a ccTLD zonefile with the necessary SIG
updates of the millions of zonefiles of its children. From experience
we know that a certain percentage of children can not be reached in
time to do this properly.
According to Cricket Liu (at the DNSSEC workshop in Sweden), the 
percentage of unreachable children is estimated to be as high as 20% 
for the .com zone. For some highly organized ccTLDs this percentage 
may be smaller, but will still present a hugh number of zones.
Another number of child nameserver systems, may be temporily
unreachable due to network- or systemproblems, also preventing
timely synchronization.

The result is, that with every key-refresh of the large TLDs many
thousands and perhaps hundreds of thousands of zones will suddenly
have bad SIGs and will drop from the Internet.

A similar problem exists when signatures expire. Although this
problem is solvable (with overlapping validity) it will cause a
enormous (administratic) burden on registries, registrants and
zone-administrators.

The question:

Miek Gieben, one of the people from NLnet Labs working on the
procedural issues of DNSSEC at ccTLDs, has asked on the dnsext en
dnsops list, why the current Bind implementations require the
parents SIG over the zone-KEY to be present in the child zone.

Reason to ask this, is that there seems no security-technical reason
to have this SIG in the parent zonefile instead.
Having this SIG in the parent zone file, and only there, would solve
both above problems. (Then, like all other SIGs, also this SIG will
be in the same zonefile as the KEY which is used to generate it, and
synchronization is automatic).

>From responses by Edward Lewis, Mats Dufberg, and Jim Reid, we
understand that the current interpretation of RFC 2535 requires
the parents SIG over the childs zone-key to be in the childzone.

We now have a problem for which I ask advice from the community.
I see two possibilities:
1. We go ahead, and accept the administratic burden and also that
   a large number of zones drop from the Internet now and then.
2. We change the interpretation of RFC 2535.

As for 1, I guess that many (large) TLDs and/or its registrants will
not be able to implement DNSSEC and that many domainholders will
prefer being unsecure over the risk of disappearing completely.

As for 2, I'm unsure what the implications are.

Please advice,
-- Ted.

---

From: [email-masked]
Date: Sat, 14 Oct 2000 09:02:12 +1100

A lot of this depends how much overlap you have with keys
	and the frequency of key changeover.

	The rollover draft is looking at a method to support this
	by automating some / all of it.  Feed back on that would be
	useful.

	As for your comment about unreachable children.  COM is not
	a good place to look for this statistic.  COM has suffered
	and still suffers from speculation.  It also suffer from
	a lack of management from above with zones allowed to be
	created w/ no operational servers.  If the parent zone
	enforces that there are operational servers *before* a
	zone is delegated the problems go down.

	Mark

--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Fri, 13 Oct 2000 10:27:18 -0400

I think the reason why the SIG(KEY) is assumed to be in the child has to do
with reducing the burden on the parent.  (Assumed to be - by the
specification, that is.)  E.g., I did the following queries:

dig @A.ROOT-SERVERS.NET. abc.com ns +norec

and

dig @DNS1.STARWAVE.COM. abc.com ns +norec

You notice that the first returns just two NS records (with a long TTL) and
the latter returns 5 NS records (and a short TTL).  This is okay - the NS
set from the child is more credible (RFC 2181) and "overwrites" the glue at
the parent.

Now, what do we do about the SIG(KEY) and KEY?  How does the above relate?

First, what happens (or what should happen) when I do a query for KEY from
abc.com?  Would the parent (.com) just issue a referral (with the KEY in
the additional section) or issue the straight answer?  What if the
signature doesn't fit in the 512 (or EDNS0 enabled larger size) meesage?

Second, what if I have the NS set for abc.com and want the KEY.  I would
issue the request directly to abc.com.  If the SIG is only at the parent,
how is it received?  There aren't "up" pointers in DNS.  (Consider that
this migh happen lower in the tree, where the parent isn't so well known as
.com.)

I am asking not in jest, but as a part of wondering about the impact of
storing the SIG(KEY) only in the parent.

BTW - do the top level delegators want to be storing the KEY's for all of
the children zone's?  I thought this would be a thing to avoid.

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

"It takes years of training to know when to do nothing" - Dogbert

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

---

From: Bill Manning <[email-masked]>
Date: Fri, 13 Oct 2000 20:16:50 -0700 (PDT)

% BTW - do the top level delegators want to be storing the KEY's for all of
% the children zone's?  I thought this would be a thing to avoid.
% 
% -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
% Edward Lewis                                                NAI Labs

	I want my childrens keys. All of them that are related to
	the delegation.

--bill

---

From: Mats Dufberg <[email-masked]>
Date: Sat, 14 Oct 2000 10:27:31 +0200 (CEST)

> the children zone's?  I thought this would be a thing to avoid.

That would increase the size of the TLD zone many times. That would
probably delay the implementation of DNSsec in TDL zones.

Mats

-----------------------------------------------------------------
Mats Dufberg                                    [email-masked]
NIC-SE                                           +46-8-545 857 06
Box 5774                                    fax: +46-8-545 857 29
SE-114 87 Stockholm                         http://www.nic-se.se/

---

From: Edward Lewis <[email-masked]>
Date: Mon, 16 Oct 2000 15:51:00 -0400

>to have this SIG in the parent zonefile instead.

How about this:

Having the parent publish the keys eliminates a beneficial three-way
handshake.   (How beneficial is open to question.)  Given the current
definition:

1) The child "signals" the intent to be secure by submitting keys to the
parent.

2) The parent "acknowledges" the child's desire to be secure by signing

3) The child "accepts" this invitation by publishing the keys.  The
important part of this step is that the child has the option, once the
parent has returned the signature, to decide if the signature is right.
I.e., what if someone adds or modifies the keys between the time the child
sends them and the parent receives them?  The parent won't know this and
publishing the erroneous keys and the signature would be a problem.

This three-way handshake is the basis of channel contention and TCP
connection establishment.

...

I think the issue comes down to "how much trust must a child put into a
parent?"  A child implicitly trusts the parent to retain the delegation.
Lame delegations  happen, and are dealt with.  Does this extend to keys?
It's debateable.

I don't think the issue is the size of the parent zone.  It has already
been pointed out that a widely delegated secured parent of unsecured
children will be rife with NULL keys and signatures.  Holding signed key
sets will be just  larger.  (How much, a negligible amount or a
considerable amount.  Evidence seems to support more like negligible.)

Is legal liability a consideration?  If the parent publishes the child's
keys, how responsible is the parent in case of a foul up?  More
importantly, is this issue a consideration?

...

On one hand I like the idea of having the parent publish the signature.
The parent made it, so is "authoritatve" for it.  On the other hand, I like
the idea of giving the child last choice on whether the parent has
validated the key set correctly.

---

From: Miek Gieben <[email-masked]>
Date: Tue, 17 Oct 2000 15:17:06 +0200

> 	by automating some / all of it.  Feed back on that would be
We've studied the draft and it is a very clever scheme for a
scheduled key rollover when a the parent's SIG is located in
the child's zone and three generations are involved.
We've looked at the implications for large zones and 
we feel that it is impractical and difficult to implement
this scheme in the ccTLD's we dealing with. What is not 
covered by this scheme is an unscheduled rollover. For instance
when a key of a middle zone (a ccTLD) gets compromised and a
rollover must take place overnight.

A few further remarks,

In section 1, fourth paragraph:
   In a widely deployed DNS security system, the volume of update
   traffic will be large.  Just consider the .com zone.  If only a few
   percent of its children are secure and change their keys only once a
   year, you are talking about hundreds of thousands of new child public
   keys that must be securely sent to the .com manager to sign and

Perhaps you could clarify what you mean by "securely sent"?
We think encryption of the channel is not needed for this kind
of communication. Authentication and verification are most important:
the parent (or .com manager) needs to know that it is signing
a key from a legitimate representative of the child.

   return with their new parent signature.  And when .com rolls over its
   private key, it will need to send hundred of thousands of new
   signatures on the existing child public keys to the child zones.

We are still wondering if this step is really needed. 

This is the table in the draft:

          BEFORE ROLLOVER        SHORTLY AFTER             AFTER ROLLOVER

       p.x     KEY      P1     p.x     KEY      P1     p.x     KEY      P1
       p.x     SIG(KEY) P1     p.x     SIG(KEY) P1     p.x     SIG(KEY) P1
       p.x     SIG(KEY) GP     p.x     SIG(KEY) GP     p.x     SIG(KEY) GP

       m.p.x   KEY      M1     m.p.x   KEY      M2     m.p.x   KEY      M2
       m.p.x   SIG(KEY) P1     m.p.x   KEY      M1     m.p.x   SIG(KEY) P1
       m.p.x   SIG(KEY) M1     m.p.x   SIG(KEY) P1     m.p.x   SIG(KEY) M2
                               m.p.x   SIG(KEY) M2

       c.m.p.x KEY      C1     c.m.p.x KEY      C1     c.m.p.x KEY      C1
       c.m.p.x SIG(KEY) M1     c.m.p.x SIG(KEY) M2     c.m.p.x SIG(KEY) M2
       c.m.p.x SIG(KEY) C1     c.m.p.x SIG(KEY) M1     c.m.p.x SIG(KEY) C1
                               c.m.p.x SIG(KEY) C1

         p = parent, m = middle, c = child, GP = grandparent key
         P* = parent key, M* = middle zone key, C* = child key

We had a problem understanding what sigs change in the table. 

If you write the table like this things maybe clearer:
(we also leave the self signed sigs out, x = label)

   BEFORE ROLLOVER           SHORTLY AFTER                  AFTER ROLLOVER
	
p.x     KEY           P1   p.x     KEY             P1    p.x     KEY          P1

m.p.x   KEY           M1   m.p.x   KEY             M1            ---            
        ---                m.p.x   KEY             M2    m.p.x   KEY          M2
m.p.x   SIG(KEY(M1))  P1   m.p.x   SIG(KEY(M1,M2)) P1    m.p.x   SIG(KEY(M2)) P1 

c.m.p.x KEY           C1   c.m.p.x KEY             C1    c.m.p.x KEY          C1
c.m.p.x SIG(KEY(C1))  M1   c.m.p.x SIG(KEY(C1))    M1            ---            
        ---                c.m.p.x SIG(KEY(C1))    M2    c.m.p.x SIG(KEY(C1)) M2

In our scheme the tables becomes:

   BEFORE ROLLOVER           SHORTLY AFTER                  AFTER ROLLOVER

p.x     KEY           P1   p.x     KEY             P1    p.x     KEY          P1
m.p.x   SIG(KEY(M1))  P1   m.p.x   SIG(KEY(M1,M2)) P1    m.p.x   SIG(KEY(M2)) P1

m.p.x   KEY           M1   m.p.x   KEY             M1            ---            
        ---                m.p.x   KEY             M2    m.p.x   KEY          M2 

(there is no interaction with the child)

Comments are appreciated,

Miek Gieben,
NLnet Labs