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

[[e-mail] (Ted Lindgreen)]

[Quoting Edward Lewis, on Apr  2,  8:17, in "Re: Signature at par ..."]

> Now, the issue is where the signature goes.  This is a related question -
> recall that there were children who didn't grab the new signatures (because
> they weren't aware of them).  So, does the delegator just cut the middleman
> and publish the signatures that it generated, or does the child need to be
> notified  by (push) or need to poll the (pull) parent.  NLnet is proposing
> cutting out the middleman...

Yes, you can say it like that.

> Yet another question...this proposal helps keep the parent-child
> relationship going, but is it secure?

Of course that's the main point!

Perhaps it is instructive to look at it from the point of view
"what can go wrong" instead of the usual "how to do it right".

Let us discuss:

- What can go wong, and how easy is that?
- What is the damage if it goes wrong?
- Is it noticed quickly, and will it be picked up?
- Can it be fixed quickly, and if so who is involved
  and what and how long does it take?
- If it can not be fixed quickly, what to do in the
  mean time?
- Can someone be blamed, made liable (or better said: can
  someone be encouraged to not make the same mistake in
  future again)?

But, first thing to review is Ed's question above: is it secure?
To discuss that, we first have to know where the vulnarabilities
are.

As far as I see, there is one and only one real security issue
at the delegation point:

 A valid parental SIG over a KEY RR, from which the private part
 is (also) known to someone else than the legitimate administrator
 of the child zone.

(Note: see NOTE below)

How can it happen?
1. The private key at the child has been compromised.
2. The parent has been fooled and thus insuffiently checked
   whether the KEY RR is really from the child.

The first one is child-problem, where it needs help
from its parent. It's discussed further on in this mail.

The second one is a delegation-administration-problem and
is discussed first:

When the initial KEY RR is sent to the parent, this is always a
difficult point. At TLDs even more complicated by the existence of
the 4 orgs involved: Registry, Registrant, Holder, and ZoneAdministrator.
Some kind of out-of-band procedure must be used, and it will most
likely involve written and signed statements and contracts with
(non-)liability clauses.  Let us not discuss this here further,
because again it is insensitive to the issue at hand.

It becomes interesting when a parent resigns.

First question is: "when" is the parent re-signing?
We (NLnet Labs) think:
 as often as practically possible, because when (not if ;-)
 something bad happens, the child is vulnarable for as
 long as the parental SIG is valid.
===> Therefore, we re-sign our test-TLD currently daily, and we do
     not sign in advance.

Next question is: "what" is the parent re-signing? When the parent
 keeps the childs-KEY in hand (either in the zonefile or a database)
 it is probably OK as long as the child does not scream
   "My KEY is compromised".
 Also can this KEY then be used to verify a new KEY at a keyrollover.
 On the other hand, if the child must resubmit its KEY RR to get
 re-signed every time this is an invitation for a spoofing attack
 every time. Bad idea we think.
===> For security sake, the parent (TLD) better holds on to the
     KEY RRs from its children.

Third question: does it matter where the parental SIG resides?
 At first one might think: yes, if the child can re-check that
 the right KEY is signed before putting the SIG in its zone, it
 is save. But.... if the bad guy has setup a fake zone, and has
 fooled the parent to sign his (fake) KEY, the bad guy will have
 little problems to put this (valid) SIG in his fake zone.
===> So, from a security point of view the answer is: NO.

Now, over to discussing what happens when a parental SIG over a
child KEY expires. This, in contrast to above, is completely
different when the SIG resides @parent of @child.

1. Parental SIG @ parent.
   What might have happened?
   - For this to happen, the (parents) zoneadministrator must
     have "forgotten" to re-sign the zone in time. As we think
     this is not a administrators-job, but a crontab-job, it's
     an unlikely event.
   - But if it happens anyway, chances are that if one is expired
     more SIGs are expired, likely all of them in the zone.
   What's the damage?
   - The parent and the whole tree below drop of the Internet
     for secure aware resolvers.
   Who will notice and make some noise?
   - A number of people will start screaming, and because of
     the damage, the zoneadministrator will probably give
     some attention to the problem.
   How to fix it?
   - He/she types "make" in the zone directory (at least,
     that's how we set it up at NLnet Labs) to refresh all
     SIGs and sigHUP named.
   Who is to blame, and how to prevent it in future?
   - The parents zoneadministrator, and he/she better puts in
     a working crontab job to re-signs the zone regularly.

2. Parental SIG @ child.
   There are now a lot more possibilities of things that could
   have gone wrong:
   - The child has not asked for a new SIG in time.
   - The net was down when the child asked.
   - The parent did not sign or did not provide the new SIG.
   - The net was down when the parent did.
   - The child could not put the new SIG in its zone for any
     other reason.
   What's the damage?
   - Depends on what happened, but probably just one of a
     few children drop of the Internet.
   Who will notice and make some noise?
   - The affected children and or its customers will notice.
   - A few helpdesks may be passed through to get to the
     attention of the parents zoneadministrator for a new
     SIG.
   - If the parent is a large TLD, chances are that when it
     is one or a few children, he/she is not too interested,
     but when it's many, he/she is overwhelmed.
   How to fix it?
   - Depending on how it is set it up (stored the KEY
     at parent?), the TLDs zoneadministrator must
     re-establish the authenticity of the childs
     zoneadministrator before signing the KEY.
   - The new SIG must get from parent to child.
   - Child must put it in and sigHUP named.
   Who is to blame, and how to prevent it in future?
   - Difficult, probably every one will point to another,
   - As it is difficut to pinpoint the cause, it is also
     difficult to prevent it from happening again.

Let us look now at another bad event:

- A child gets its key compromised.
- Let's pick a large TLD, with
- most children not very sensitive to
  security, but some (still hundreds of thousands) are,
- and a few (say a hundredthousand) secure subtrees (next
  to the millions of end-zones).

Let's go through the questions:

   What might have happened?
   - The TLDs key got compromised.
   What's the damage?
   - The TLDs and all zones thereunder are vulnarable.
   Who will notice and make some noise?
   - Hopefully someone finds out before misuse has really
     started...
   How to fix it?
 This now depends on what the TLD chooses to do, and where
 its SIGs over the childs KEY RRs reside.
 2 x 2 posibilities:
 1A. TLD becomes unsecure immediately, SIG @ parent
 1B. TLD rolls over its KEY immediately, SIG @ parent
 2A. TLD becomes unsecure immediately, SIG @ child
 2B. TLD rolls over its KEY immediately, SIG @ child

 So, again, how to fix it?
 1A. TLD becomes unsecure immediately, SIG @ parent.
   - TLD goes to root with a request to become
     unsecure immediately.
   - Root's zone administrator needs to establish
     authenticity of request and requester out-of-band.
   - Root's zone administrator puts in a null-KEY for
     TLD into rootzone, re-signs, and sigHUPs.
   - Where the old KEY and old SIGs are cached (or spoofed
     into the cache!!!) they remain valid intil the SIGs
     expire. Nothing we can do about that.
   - Once the old SIG expires, the TLD and all zones below
     are now verifyably unsecure, and therefore:
     - secure transactions will know that they
       cannot trust DNS info.
     - do not drop of the Internet
   - TLD starts investigating what went wrong, fix that
     and gets more or less into the state of
      "becoming first-time secure": once it has signed its
      own zone with a new KEY and got the new KEY also
      signed at the root everything is back to normal.

 1B. TLD rolls over its KEY immediately, SIG @ parent.
   - TLD goes to root with an immergency KEY rollover
     request.
   - Root's zone administrator needs to establish
     authenticity of request and requester out-of-band.
   - Root's zone administrator puts in the new TLD-KEY
     into rootzone, re-signs, and sigHUPs.
   - The TLD puts the new KEY in its zone and re-signs.
   - Where the old KEY and old SIGs are cached (or spoofed
     into the cache!!!) they remain valid intil the SIGs
     expire. Nothing we can do about that.
   - As soon as the old SIG expires, everything is back
     to normal.

 2A. TLD becomes unsecure immediately, SIG @ child
   - TLD goes to root with a request to become
     unsecure immediately.
   - Root's zone administrator needs to establish
     authenticity of request and requester out-of-band.
   - Root's zone administrator puts in a null-KEY for
     TLD into rootzone, re-signs, and sigHUPs.
   - Where the old KEY and old SIGs are cached (or spoofed
     into the cache!!!) they remain valid intil the SIGs
     expire. Nothing we can do about that.
   - Once the old SIG expires, the TLD and all zones below
     are now verifyably unsecure (see above).
   - TLD starts investigating what went wrong, fix that.
   - TLD can not get into "becoming first-time secure",
     because it has SIGs from the compromised KEY out
     there at all its children, they MUST be replaced
     before the TLD can become secure again with a new
     KEY. This may take some time for a large TLD.

 2B. TLD rolls over its KEY immediately, SIG @ child.
   We tried several scenarios, but we have not found an
   acceptable way.
   The possible choices are:
   1. Allow secure children to be exposed.
   2. Allow secure children to drop from the Internet.
   3. Use scenario 2A to become unsecured for a reasonably
      long time to clean up, and then become secure again.

We have worked out several more scenarios  (I admit, they are all
"horror scenarios", but nontheless likely to happen sooner or
later), but I think this e-mail got too long already :-)

Regards,
-- Ted.

NOTE:  Someone said: what if the parent puts in a wrong or mistyped
childs KEY in its zone, isn't that a security risk? This is IMHO
not a security issue, it is "just" bad zoneadministration and
similar to mistyped or wrong NS or glue RRs at the parent zone.
Also, it does not expose the child, the parent "just" disables the
child, unless, of course, the "mistyped" KEY happens to be the KEY
from mr. Bad Guy, but then we are back to the security issue
already mentioned.



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